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ABSTRACT 


The  Cultural  Geography  (CG)  Model  is  a  low-resolution,  agent-based  discrete 
event  social  simulation  tailored  to  specific  operational  environments.  It  is  based 
on  doctrine  and  social  theory  designed  to  represent  the  behavioral  response  of 
civilian  populations  in  conflict  environments.  The  current  version  of  the  CG  Model 
does  not  represent  key  leader  engagements  (KLE),  which  are  activities  between 
coalition  military  forces  and  host  nation  civilian  personnel,  as  means  of  obtaining 
information,  influencing  behavior,  and  building  an  indigenous  base  of  support  for 
coalition  and  government  objectives.  These  capabilities  are  needed  for  additional 
tactical  level  representation  of  the  operational  environment. 

This  research  develops  a  simulation  model  using  Simkit  to  explore  the 
feasibility  of  modeling  KLEs  using  discrete  event  simulation.  A  total  of  32 
dynamic  input  factors  are  varied  using  a  512-design  point  design.  Second-order 
regression  metamodels  and  partition  tree  models  are  developed  for  simulation 
model  output  responses  that  track  numbers  of  engagements,  numbers  of  times 
knowledge  is  provided,  numbers  of  campaigns,  and  numbers  of  captures  and 
kills;  these  analytical  models  are  used  to  verify  the  proper  execution  of  the 
simulation  model.  Summary  statistics  are  analyzed  to  gain  further  insights  about 
the  simulation  model’s  behavior. 
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EXECUTIVE  SUMMARY 


The  Cultural  Geography  (CG)  Model,  developed  by  TRAC-Monterey,  is  a 
low-resolution,  agent-based,  discrete  event  social  simulation  tailored  to  specific 
operational  environments  based  on  doctrine  and  social  theory.  It  is  designed  to 
represent  the  behavioral  responses  of  civilian  populations  in  conflict 
environments.  It  focuses  on  the  political,  military,  economic,  social,  infrastructure, 
and  information  variables  in  the  operational  environment,  which  affect  the 
population’s  beliefs,  values,  interests,  attitudes,  and  behaviors.  TRAC-Monterey 
developed  the  model  to  support  the  analysis  of  civilian  population  perception 
based  on  friendly  and  threat  actions. 

The  current  version  of  the  CG  Model  does  not  represent  key  leader 
engagements  (KLE),  which  are  activities  between  coalition  military  forces  and 
host  nation  civilian  personnel  as  a  means  of  obtaining  information,  influencing 
behavior,  and  building  an  indigenous  base  of  support  for  coalition  and 
government  objectives.  TRAC  needs  this  capability  for  additional  tactical  level 
representation  of  the  operational  environment.  TRAC’s  Irregular  Warfare  (IW) 
Tactical  Wargame  (TWG)  initiative  utilizes  Nexus,  an  interpretive  social  science 
simulation  of  IW  that  is  separate  from  the  CG  Model,  to  incorporate  the  influence 
of  key  individuals  on  the  population  by  modeling  the  key  leader  network.  One  of 
the  focus  areas  discussed  in  the  after-action  report  from  the  TWG  that  TRAC- 
Monterey  held  in  October  201 1  was  a  need  to  incorporate  the  Nexus  key  leader 
functionality  into  the  existing  CG  Model.  TRAC  seeks  to  remodel  the  components 
of  Nexus  as  discrete  event  simulation  using  Simkit,  the  basis  for  the  CG  Model. 
Currently  the  CG  Model  takes  the  Nexus  outputs  as  a  subset  of  its  inputs  to 
study  a  larger  cultural  population. 

This  thesis  project  explores  three  research  questions.  First,  can  we 
satisfactorily  model  KLEs  using  discrete  event  simulation  and  Simkit?  After 
conducting  an  initial  analysis  of  the  KLE  components  within  Nexus,  we 
developed  a  discrete  event  simulation  model  that  captured  the  critical 


xv 


functionality  of  Nexus.  This  functionality  includes  conducting  KLEs,  agreeing  to 
pass  coalition  force  messages,  honoring  critical  knowledge  requests, 
campaigning  by  key  leaders,  and  capturing,  killing,  releasing,  and  replacing  key 
leaders.  Additionally,  we  included  micro-KLEs,  or  interactions  with  the  general 
populace  to  extract  critical  knowledge.  Our  model  involved  the  creation  of  model 
agents,  the  development  of  agent  behaviors  based  primarily  on  an  attribute 
called  observed  attitude  and  behavior  (OAB),  and  the  definition  and  development 
of  parameters,  state  variables,  and  event  graphs.  We  then  translated  the  agents, 
behaviors,  and  event  graphs  into  computer  code  using  Java  and  Simkit  for  direct 
closed-loop  analysis.  Upon  exploring  the  feasibility  of  modeling  KLEs,  we  were 
able  to  create  a  simple,  yet  realistic,  discrete  event  simulation  model  of  KLEs. 

Second,  how  can  experimental  design  be  used  to  assist  in  code 
verification  efforts?  Once  complete  with  the  discrete  event  simulation  modeling, 
simulation  scenarios  were  developed  to  study  the  KLE  Model  and  to  provide 
insight  on  what  model  input  parameters  have  the  greatest  impact  on  influencing 
model  output  behaviors.  Large-scale  experiments  were  designed  and  employed 
to  vary  the  32  input  parameters  in  a  structured,  efficient  manner  in  order  to  assist 
with  code  verification  efforts.  Three  separate  scenario  runtimes  were  used:  one 
week  to  study  short-term  model  effects,  nine  weeks  to  study  the  effects  during  a 
typical  TWG  runtime,  and  one  year  to  study  long-term  model  effects.  After 
building  regression  metamodels  and  partition  tree  models  for  the  output 
responses,  our  analysis  highlighted  several  input  factors  that  were  important  in 
predicting  all  of  the  output  responses,  such  as  the  probability  a  key  leader 
reneges  from  a  KLE,  the  probability  a  key  leader  is  a  no-show  to  a  KLE,  and  the 
probability  a  key  leader  honors  message  or  knowledge  requests.  The 
identification  of  significant  input  parameters  was  then  used  to  verify  the  proper 
functionality  of  our  model  by  using  them  to  explain  expected  behavior  of  the 
model  components. 

Third,  are  there  any  insights  we  can  gain  from  the  model  using  the  output 
summary  statistics  coupled  with  histograms  and  boxplots,  such  as  variability 


issues  or  outlier  issues?  The  analysis  showed  that  most  of  the  output  responses 
provide  plausible  ranges  and  variations,  thus  verifying  the  reasonableness  of  our 
model  outputs.  Outliers  did  not  appear  to  be  an  issue.  One  output  that  did  not 
behave  as  expected  was  the  number  of  micro-KLEs  response.  This  appeared 
anomalous  as  it  exhibited  exponential  growth.  After  further  investigation,  we 
found  that  the  results  were  consistent  with  the  input  parameters  provided  by 
TRAC,  because  a  large  number  of  potential  micro-KLEs  could  be  conducted 
when  key  leaders  were  unavailable. 

In  summary,  we  have  built  a  conceptual  model  of  the  impact  of  key  leader 
engagements  on  civilian  population  behavior,  implemented  this  model  using  a 
discrete  event  simulation  approach,  and  tested  its  performance  with  a  large-scale 
experiment.  This  sets  the  stage  for  incorporating  our  KLE  Model  into  the  current 
CG  Model,  in  order  to  improve  the  CG  Model’s  suitability  for  use  in  tactical 
wargames  and  other  studies. 
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I.  INTRODUCTION 


Chapter  I  begins  with  some  background  about  why  this  thesis  was 
conducted,  basically  stemming  from  a  need  for  key  leader  engagement 
functionality  for  a  United  States  Army  irregular  warfare  model.  Next  it  describes 
what  key  leaders,  observed  attitudes  and  behaviors,  key  leader  engagements, 
and  micro-key  leader  engagements  are.  An  overview  of  the  methodology  is 
outlined,  concluding  with  the  research  questions  that  were  posed. 

A.  MOTIVATION  FOR  THESIS 

1.  TRAC  and  the  Cultural  Geography  Model 

The  United  States  Army  Training  and  Doctrine  Command  Analysis  Center, 
or  TRAC,  supports  the  United  States  Army  by  conducting  operational  analysis  to 
inform  Army  decisions.  TRAC-Monterey,  co-located  with  the  Naval  Postgraduate 
School  in  Monterey,  California,  is  the  research  and  analysis  arm  of  TRAC.  It 
specializes  in  relevant,  credible  exploratory  and  applied  research  related  to 
modeling,  simulation,  and  analysis  methodologies. 

The  Cultural  Geography  (CG)  Model,  developed  by  TRAC-Monterey,  is  a 
low-resolution,  agent-based,  discrete  event  social  simulation  tailored  to  specific 
operational  environments  based  on  doctrine  and  social  theory.  It  is  designed  to 
represent  the  behavioral  responses  of  civilian  populations  in  conflict 
environments.  It  focuses  on  the  political,  military,  economic,  social,  infrastructure, 
and  information  variables  in  the  operational  environment,  which  affect  the 
population’s  beliefs,  values,  interests,  attitudes,  and  behaviors.  TRAC-Monterey 
developed  the  model  to  support  the  analysis  of  civilian  population  perception 
based  on  friendly  and  threat  actions. 

The  CG  Model  is  built  around  the  concept  of  reusable  “plug-and-play” 

Java  modules  that  formalize  theories  from  behavioral  and  social  science.  It  is 

implemented  in  Java  and  utilizes  Simkit  as  the  simulation  engine.  It  blends  a 

variety  of  carefully  selected  social  science  theories  with  current  and  emerging 
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counterinsurgency  and  stability  operations  doctrine.  It  employs  a  social  network 
for  population  entities  and  a  bipartite  network  between  groups  and  population 
entities  to  represent  the  evolving  relationships  and  interactions  over  time.  The 
civilian  population  entities  and  adversary  entities  have  deep  intelligence 
representations  to  allow  those  agents  to  react  to  events  and  information,  and  to 
change  positions  and  affiliations  over  time  with  a  clear  understanding  of  motive. 

2.  Need  for  Key  Leader  Engagement  Functionality 

The  current  version  of  the  CG  Model  does  not  represent  key  leader 
engagements,  which  are  activities  between  coalition  military  forces  and  host 
nation  civilian  personnel  as  a  means  of  obtaining  information,  influencing 
behavior,  and  building  an  indigenous  base  of  support  for  coalition  and 
government  objectives.  TRAC  needs  this  capability  for  additional  tactical  level 
representation  of  the  operational  environment. 

TRAC’s  Irregular  Warfare  (IW)  Tactical  Wargame  (TWG)  initiative  utilizes 
Nexus,  an  interpretive  social  science  simulation  of  IW  that  is  separate  from  the 
CG  Model,  to  incorporate  the  influence  of  key  individuals  on  the  population  by 
modeling  the  key  leader  network.  One  of  the  focus  areas  discussed  in  the  after¬ 
action  report  from  the  TWG  that  TRAC-Monterey  held  in  October  2011  was  a 
need  to  incorporate  the  Nexus  key  leader  functionality  into  the  existing  CG 
Model.  In  an  effort  to  create  an  integrated,  simplified,  and  stable  model  that 
encompasses  social  interactions  and  cultural  impacts,  TRAC-Monterey  is 
creating  a  new  model,  the  Social  Impacts  Module,  or  SIM.  The  goal  is  to  have 
SIM  complete  by  the  next  TWG  scheduled  for  the  spring  of  2013. 

The  Nexus  Key  Leader  Model,  a  part  of  the  Nexus  suite,  is  a  cognitive 
agent-based  model  that  focuses  on  individual,  discrete  interactions  among 
agents  such  as  those  found  in  key  leader  engagements.  Nexus  utilizes  Repast, 
an  agent-based  modeling  and  simulation  toolkit.  Agent  behaviors  and  symbolic 
interactionism  are  derived  from  interpretive  social  science.  Agents  individually 
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adapt  to  civil  and  military  intervention  using  Artificial  Intelligence  Technologies, 
and  so  they  implement  cultural  rules  using  probabilistic  ontologies.  (Duong  n.d.) 

TRAC  seeks  to  remodel  the  components  of  Nexus  as  discrete  event 
simulation  using  Simkit,  the  basis  for  the  CG  Model.  Currently  the  CG  Model 
takes  the  Nexus  outputs  as  a  subset  of  its  inputs  to  study  a  larger  cultural 
population.  This  thesis  project  looks  at  the  feasibility  for  the  seamless  integration 
of  the  Nexus-based  code  into  the  CG  Model,  thus  providing  improved  continuity 
of  the  input  parameters  and  the  output  data. 

B.  KEY  LEADERS  AND  KEY  LEADER  ENGAGEMENTS 

1 .  Key  Leaders 

Key  leaders  are  the  formal  or  informal  leaders  that  are  powerful  in  a 
society  and  can  influence  a  target  audience  in  a  way  that  is  beneficial  for 
coalition  operations.  In  the  context  of  a  TWG,  key  leaders  are  of  two  types.  The 
first  type  is  the  coalition  force  representative,  or  military  commander,  represented 
by  the  physical  player  of  the  TWG;  the  human  player  has  a  simulated 
representation  in  the  model.  The  second  type  is  the  key  actor  in  the  mission  area 
with  whom  the  military  commander  wants  to  engage;  this  is  the  powerbroker, 
stakeholder,  or  otherwise  influential  voice  within  the  community  and  culture  being 
studied,  represented  by  a  simulated  entity  within  the  model.  Key  leaders  are  one 
of  the  primary  means  through  which  players  may  influence  the  population.  They 
can  provide  critical  knowledge  about  other  key  leaders,  threats,  or  resources, 
pass  messages  to  the  population,  or  inform  players  as  to  issue  stances  regarding 
community  concerns. 

Key  leaders  can  be  encouraged  (monetarily  or  non-monetarily)  or 
threatened.  They  can  be  captured  or  killed  through  player  action,  and  if  this 
occurs,  the  network  of  leaders  within  the  game  will  reorganize  through  an 
adjudication  process,  and  influences  may  change.  Players  begin  with  a  unique 
list  of  known  key  leaders.  Additional  key  leaders  will  be  revealed  throughout  the 
game  as  the  players  form  relationships  with  the  population. 
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The  motivation  for  key  leaders  to  act  a  particular  way  toward  coalition 
forces  comes  from  an  attribute  called  observed  attitudes  and  behaviors  (OAB). 
This  is  a  key  leader’s  general  attitude  toward  coalition  forces,  either  positive  or 
negative,  coupled  with  their  propensity  to  act  a  certain  way,  either  active  or 
passive.  The  OAB  types  of  the  key  leaders  in  this  study  are  positive  active  (will 
go  out  of  their  way  to  help  you),  positive  passive  (like  you  but  will  generally  stay 
out  of  the  way),  neutral,  negative  passive  (do  not  like  you  but  will  generally  stay 
out  of  the  way),  and  negative  active  (will  go  out  of  their  way  to  hurt  you). 

2.  Key  Leader  Engagements 

The  interactions  between  the  physical  players  and  simulated  entities  are 
called  key  leader  engagements  (KLE).  KLEs  are  planned  to  convey  selected 
information  and  indicators  to  foreign  audiences  to  influence  their  emotions, 
motives,  objective  reasoning,  and  ultimately  the  behavior  of  foreign  governments, 
organizations,  groups,  and  individuals.  They  are  held  in  order  to  collect 
intelligence,  develop  relationships  in  support  of  commander’s  intent,  and  obtain 
mutually  satisfying  outcomes  within  constraints  existing  in  a  partnered  nation’s 
cultural  belief  system. 

In  general,  a  KLE  is  more  than  just  a  meeting,  mini-conference,  or  working 
group  between  the  military  leaders  and  the  local  population.  They  are  exploratory 
engagements  in  order  for  both  sides  to  identify  one  another's  motives.  KLEs 
enable  military  leaders  and  decision  makers  to  interact  with  key  leaders  and  the 
local  populace  in  order  to  begin  or  build  relations.  In  addition,  KLEs  enable 
military  leaders  to  identify  the  key  issues  and  concerns  of  the  population 
(McKenna  and  Hampsey  2010). 

A  subset  of  KLEs  consists  of  micro-KLEs.  These  deal  with  getting 
information  from  civilians  within  the  general  population.  Micro-KLEs  have 
outcomes  that  are  associated  with  the  OAB  of  the  civilian,  and  the  civilian  that  is 
chosen  to  interact  with  is  usually  selected  at  random.  Based  on  that  person’s 
social  network,  he  or  she  might  know  something  about  a  key  leader,  a  threat,  or 
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a  resource,  and  based  on  that  person’s  motivations,  he  or  she  might  tell  a  human 
player  what  they  know.  Not  every  micro-KLE  results  in  useful  information,  and  so 
the  probability  of  getting  actionable  information  is  usually  low. 

C.  RESEARCH  QUESTIONS 

1.  Satisfactorily  Modeling  KLEs 

Can  we  satisfactorily  model  KLEs  using  discrete  event  simulation  and 
Simkit?  Additionally,  are  we  gaining  or  losing  (or  willing  to  lose)  any  important 
KLE  functionality  from  the  current  method  of  using  a  third-party  model?  Upon 
exploring  the  feasibility  of  modeling  KLEs,  we  were  able  to  create  a  simple,  yet 
realistic,  discrete  event  simulation  model  of  KLEs.  This  model  also  included  the 
ability  to  look  at  micro-KLEs,  a  function  not  found  within  Nexus  but  identified  by 
TRAC  as  important  for  SIM. 

2.  Significant  Input  Parameters  and  Code  Verification 

What  input  parameters  are  significant  when  predicting  the  model  output 
responses?  Can  these  significant  factors  assist  with  code  verification  efforts? 
Through  the  use  of  second-order  regression  metamodels  and  partition  tree 
models,  our  analysis  highlighted  several  input  parameters  that  were  statistically 
significant  in  predicting  all  of  the  output  responses.  In  most  cases,  the 
metamodels  and  tree  models  backed  each  other  up.  Additionally,  the  factors 
found  to  be  most  significant  helped  verify  the  expected  behavior  of  the  model 
components. 

3.  Summary  Statistic  Insights 

Are  there  any  insights  we  can  gain  from  the  model  using  the  output 
summary  statistics,  such  as  variability  issues  or  outlier  issues?  The  analysis 
showed  that  most  of  the  output  responses  provide  plausible  ranges  and 
variations,  thus  verifying  the  reasonableness  of  our  model  outputs.  Outliers  did 
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not  appear  to  be  an  issue.  Furthermore,  the  summary  statistics  showed  us  that 
the  number  of  micro-KLEs  response  appeared  anomalous  as  it  exhibited 
exponential  growth. 

D.  METHODOLOGICAL  APPROACH 

We  conducted  an  initial  analysis  of  the  KLE  components  within  Nexus. 
The  goal  was  to  identify  and  understand  the  critical  components  of  the  network 
relating  to  KLEs.  We  remodeled  these  critical  components  using  discrete  event 
simulation.  This  involved  the  creation  of  model  agents,  the  development  of  agent 
behaviors,  and  the  definition  and  development  of  parameters,  state  variables, 
and  event  graphs.  We  then  translated  the  agents,  behaviors,  and  event  graphs 
into  computer  code  using  Java  and  Simkit  for  direct  closed-loop  analysis. 

Additionally,  the  CG  Model  currently  uses  Bayesian  belief  networks  to 
model  the  population  stance  changes.  Another  project  within  TRAC-Monterey’s 
scope  is  to  explore  the  possibility  of  modeling  the  population  behavior  using 
Markov  chains  instead  of  the  Bayesian  belief  networks.  To  conform  to  this 
updated  population  behavior  methodology,  Markov  chains  were  utilized  in 
modeling  the  key  leader  OAB  changes  and  assignments. 

Once  we  completed  the  discrete  event  simulation  modeling,  simulation 
scenarios  were  developed  to  study  the  KLE  Model  and  to  provide  insight  on  what 
model  input  parameters  have  the  greatest  impact  on  influencing  model  output 
behaviors.  Large-scale  experiments  (Kleijnen  et  al.  2005,  Vieira  et  al.  201 1)  were 
designed  and  employed  to  vary  the  input  parameters  in  a  structured,  efficient 
manner  in  order  to  assist  with  code  verification  efforts.  Output  responses  similar 
to  those  in  Nexus  were  identified,  developed,  and  added  to  the  KLE  Model  to 
gather  information  from  the  model  for  statistical  analysis. 

The  simulation  output  data  were  collected  and  analyzed  to  identify  and 
build  any  useful  statistical  relationships  that  can  help  predict  model  input 
outcomes.  Analysis  tools  used  included  second-order  regression  metamodels, 
partition  tree  models,  summary  statistics,  histograms,  and  boxplots. 
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We  provide  details  about  the  KLE  Model  in  Chapter  II.  In  Chapter  III  we 
describe  the  experimental  design  used  to  investigate  the  KLE  Model’s 
performance.  Chapter  IV  contains  our  analysis  and  assessment  of  13  different 
model  responses.  Conclusions  and  suggestions  for  further  research  appear  in 
Chapter  V. 
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II.  KEY  LEADER  ENGAGEMENT  MODEL 


Chapter  II  begins  with  a  description  of  the  requirements  needed  for  a 
closed-loop  model  of  key  leader  engagements  (KLE).  Some  of  these 
requirements  are  highlighted  in  TRAC-Monterey  supporting  documentation,  while 
others  are  a  carryover  from  the  Nexus  KLE  functionality.  Next,  we  discuss  the 
three  types  of  agents  used  in  the  model,  namely  Blue  players,  Green  players, 
and  Red  players,  followed  by  behavior  equations  that  are  used  to  model  agent 
behaviors.  Lastly,  the  event  graphs  and  components  that  we  built  are  described 
in  detail,  including  the  component  listening  structure  and  adapters. 

A.  REQUIREMENTS  OF  KLE  MODEL 

Specific  requirements  for  integrating  Nexus  into  the  Cultural  Geography 
(CG)  Model  are  outlined  in  Caldwell  and  Brown  (2011).  The  model  must  allow 
agents  to  update  their  observed  attitudes  and  behaviors  (OAB),  consent  to  pass 
a  message,  and  provide  critical  knowledge  on  key  leaders,  threats,  and/or 
resources.  Other  components  are  required  to  integrate  with  the  CG  Model,  but 
the  KLE  Model  in  this  research  is  run  independently  from  the  CG  Model,  so  those 
functions  are  not  explicitly  implemented.  The  requirements  document  does  not 
outline  some  of  the  KLE  functionality,  but  it  is  a  continuation  from  the  legacy 
version  of  Nexus  and  used  in  comparing  the  KLE  Model  outputs  to  the  tactical 
wargame  (TWG)  results;  these  functions  are  campaigning,  capturing,  killing,  and 
replacing  key  leaders. 

In  order  to  model  KLEs,  we  need  to  model  agents,  behaviors,  and  events. 
The  agents  represented  in  the  model  are  Blue  players  (coalition  force  military 
commanders),  Green  players  (key  leaders),  and  Red  players  (anti-coalition  force 
and/or  anti-key  leader  personnel).  The  behaviors  are  represented  by  simple 
equations  or  probability  transition  matrices  utilizing  OABs,  probability  factors, 
probabilities,  and  times. 
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The  components  used  in  this  model  allow  for  a  closed-loop  execution  of 
events  that  are  based  on  discrete  event  simulation  using  Simkit.  For  more 
information  on  discrete  event  simulation  modeling  and  discrete  event 
programming  with  Simkit,  see  Buss  (201 1 ). 

The  KLE  Model  requirements  include: 

•  Method  to  create  agents; 

•  Method  to  figure  out  if  Blue  players  are  seeking  out  micro-KLEs  or 
scheduling  KLEs,  to  include  reneges  and  no-shows; 

•  Method  to  handle  micro-KLEs  and  potentially  gain  critical 
knowledge; 

•  Methods  to  handle  KLEs  and  potentially  persuade  Green  players  to 
pass  messages,  provide  critical  knowledge,  and/or  update  their 
OAB; 

•  Method  to  handle  Green  player  campaigns; 

•  Method  to  handle  capturing  and  killing  of  Green  players; 

•  Method  to  handle  releasing  of  Green  players;  and 

•  Method  to  handle  Green  player  replacements. 

B.  AGENTS  IN  KLE  MODEL 

1.  BluePlayer  Agent 

A  BluePlayer  agent  in  the  KLE  Model  represents  a  United  States  military 
commander  or  coalition  force  commander  that  has  the  authority  to  conduct 
micro-KLEs  and  partake  in  KLEs.  The  agent  has  three  attributes,  summarized  in 
Table  1.  The  attribute  name  is  self-explanatory.  The  attribute  id  is  a  unique 
integer  identification  for  the  Blue  player  to  help  identify  the  agent  in  the  model. 
The  first  Blue  player  created  has  an  id  of  1;  each  subsequent  Blue  player  created 
has  the  next  incremental  integer.  The  attribute  incentiveToOffer  is  a  Boolean- 
type  used  to  show  if  the  Blue  player  has  an  incentive  to  offer  to  a  Green  player 
during  a  KLE. 
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Attribute 

Type 

Description 

name 

String 

name  of  Blue  player 

id 

int 

integer  identification  of  Blue  player 

incentiveToOffer 

boolean 

Blue  player  has  (true)  or  does  not  have 
(false)  an  incentive  to  offer  a  Green  player 

Table  1.  BluePlayer  agent  attributes. 


2.  GreenPlayer  Agent 

A  GreenPlayer  agent  in  the  KLE  Model  represents  the  influential  key 
leader.  The  agent  has  16  attributes,  summarized  in  Table  2.  The  attribute  name 
is  self-explanatory.  The  attribute  id  is  a  unique  integer  identification  for  the  Green 
player  to  help  identify  the  agent  in  the  model.  The  first  Green  player  created  has 
an  id  of  1;  each  subsequent  Green  player  created  has  the  next  incremental 
integer.  The  attribute  observedAttitudeBehavior  holds  the  current  OAB  for  the 
Green  player.  The  following  are  the  corresponding  OAB  values  for  the 
representative  integers:  0  is  negative  active,  1  is  negative  passive,  2  is  neutral,  3 
is  positive  passive,  and  4  is  positive  active.  The  attribute  corrupt  is  a  Boolean- 
type  used  to  show  if  the  Green  player  is  corrupt  and  will  be  enticed  by  incentives 
offered  during  KLEs.  The  attribute  agreedToPassMessage  is  a  Boolean-type 
used  to  show  if  the  Green  player  has  agreed  to  pass  along  a  message  from  a 
Blue  player  during  a  KLE.  The  attribute  keyLeaderKnowledge  is  a  Boolean-type 
used  to  show  if  the  Green  player  has  critical  knowledge  on  other  key  leaders  to 
provide  to  a  Blue  player  during  a  KLE.  The  attribute  threatKnowledge  is  a 
Boolean-type  used  to  show  if  the  Green  player  has  critical  knowledge  on  threats 
to  provide  to  a  Blue  player  during  a  KLE.  The  attribute  resourceKnowledge  is  a 
Boolean-type  used  to  show  if  the  Green  player  has  critical  knowledge  on 
resources  to  provide  to  a  Blue  player  during  a  KLE. 

The  attribute  incentivized  is  a  Boolean-type  used  to  show  if  the  Green 
player  has  been  offered  an  incentive  during  a  KLE.  The  attribute  threatened  is  a 
Boolean-type  used  to  show  if  the  Green  player  has  been  presented  a  threat 
during  a  KLE.  The  attribute  killed  holds  the  current  killed  status  of  the  Green 
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player  as  an  integer;  0  corresponds  to  alive,  1  corresponds  to  killed  by  a  Blue 
player,  and  2  corresponds  to  killed  by  a  Red  player.  The  attribute  captured  holds 
the  current  captured  status  of  the  Green  player  as  an  integer;  0  corresponds  to 
not  captured,  1  corresponds  to  captured  by  a  Blue  player,  and  2  corresponds  to 
captured  by  a  Red  player.  The  attribute  replacement  represents  another 
GreenPlayer  agent  who  is  a  replacement  for  the  Green  player  if  he  is  captured  or 
killed.  The  attribute  kleStartTimeStamp  is  used  to  mark  the  beginning  of  a  KLE. 
The  attribute  kleEndTimeStamp  is  used  to  mark  the  end  of  a  KLE.  The  attribute 
campaignTimeStamp  is  used  to  mark  the  start  of  a  campaign. 
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Attribute 

Type 

Description 

name 

String 

name  of  Green  player 

id 

int 

integer  identification  of  Green  player 

observedAttitudeBehavior 

int 

Green  player's  observed  attitude  and  behavior 
towards  Blue  players 
(0  =  negative  active 

1  =  negative  passive 

2  =  neutral 

3  =  positive  passive 

4  =  positive  active) 

corrupt 

boolean 

Green  player  is  (true)  or  is  not  (false)  corrupt 

agreedToPassMessage 

boolean 

Green  player  has  (true)  or  has  not  (false) 
agreed  to  pass  a  Blue  player's  message 

keyLeaderKnowledge 

boolean 

Green  player  has  (true)  or  does  not  have  (false) 
critical  knowledge  on  other  key  leaders 

threatKnowledge 

boolean 

Green  player  has  (true)  or  does  not  have  (false) 
critical  knowledge  on  threats 

resourceKnowledge 

boolean 

Green  player  has  (true)  or  does  not  have  (false) 
critical  knowledge  on  resources 

incentivized 

boolean 

Green  player  has  (true)  or  has  not  (false)  been 
incentivized 

threatened 

boolean 

Green  player  has  (true)  or  has  not  (false)  been 
threatened 

killed 

int 

killed  status  of  Green  player 
(0  =  alive 

1  =  killed  by  Blue  player 

2  =  killed  by  Red  player) 

captured 

int 

captured  status  of  Green  player 
(0  =  not  captured 

1  =  captured  by  Blue  player 

2  =  captured  by  Red  player) 

replacement 

GreenPlayer 

Green  player  replacement  for  a  killed  or 
captured  Green  player 

kleStartTimeStamp 

double 

time  stamp  used  to  mark  the  beginning  of  a  KLE 

kleEndTimeStamp 

double 

time  stamp  used  to  mark  the  end  of  a  KLE 

campaignTimeStamp 

double 

time  stamp  used  to  mark  the  start  of  a 
campaign 

Table  2.  GreenPlayer  agent  attributes. 
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3.  RedPlayer  Agent 

A  RedPlayer  agent  in  the  KLE  Model  represents  a  person  who  is  the 
enemy  of  the  United  States  or  coalition  forces,  or  even  of  key  leaders,  and  does 
not  want  collaboration  between  Blue  players  and  Green  players.  A  Red  player 
could  be  in  direct  competition  with  a  Blue  player  for  the  favor  of  a  Green  player, 
but  this  behavior  is  not  modeled.  Based  on  certain  actions  of  Green  players,  Red 
players  capture  or  kill  Green  players.  A  Red  player  does  not  have  a  physical 
representation  within  the  model  and  is  only  referenced  or  implied  through  event 
names. 

C.  BEHAVIOR  EQUATIONS  IN  KLE  MODEL 

The  KLE  Model  uses  several  “behavior  equations”  to  control  certain 
actions  by  the  players.  These  equations  use  simple  logic  to  determine 
probabilities  that  players  carry  out  a  particular  action.  In  all  cases,  the  calculated 
probability  or  probabilities  are  referenced  against  a  random  uniform  draw 
between  0  and  1  to  see  if  the  player  behaves  a  particular  way. 

Behavior  Equation  1  (Figure  1)  is  used  to  see  if  a  Blue  player  can  gain 
knowledge  during  micro-KLEs  or  have  requests  honored  during  KLEs.  It  has 
three  variables.  The  first  represents  the  OAB  value,  an  integer  between  0  and  4, 
of  a  player.  The  second  is  a  random  uniform  draw  between  0  and  1 .  The  third  is 
a  probability  factor,  assumed  to  be  between  0  and  0.2.  The  equation  takes  the 
OAB  and  adds  to  it  the  random  uniform  draw.  The  result  is  then  multiplied  by  the 
probability  factor.  This  gives  a  resulting  probability  that  will  always  be  between  0 
and  1 .  The  purpose  of  the  equation  is  to  give  a  range  of  probabilities  for  the 
player  to  access,  and  for  the  probabilities  to  be  increasingly  higher  as  the  OAB 
value  increases.  For  instance,  if  the  probability  factor  is  0.1,  a  player  with  an  OAB 
of  0  will  have  a  behavior  probability  between  0  and  0.1.  Likewise,  a  player  with 
an  OAB  of  4  will  have  a  behavior  probability  between  0.4  and  0.5.  In  both  cases, 
a  separate  random  uniform  draw  is  compared  to  the  probability  range. 
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/‘{Blue  player  gains  knowledge  during  micro-KLE  or 
has  reque  st  honored  during  KLE} 

=  {OAR+U)*pf 

where  OAB  =  observed  attitude  and  behavior  ,  between  0  and  4 
U  ~  £fa^a™(0,l} 

pf  =  probability  factor  between  0  and  0 .2 
Figure  1 .  Behavior  Equation  1 

Behavior  Equation  2  (Figure  2)  is  used  to  see  if  a  Green  player  is  going  to 
renege  from  or  be  a  no-show  to  a  planned  KLE  and  to  see  if  a  Blue  player  will 
offer  a  threat  to  a  Green  player  during  a  KLE.  It  has  three  variables.  The  first 
represents  the  OAB  value,  an  integer  between  0  and  4,  of  a  player.  The  second 
is  a  random  uniform  draw  between  0  and  1 .  The  third  is  a  probability  factor, 
assumed  to  be  between  0  and  0.2.  The  equation  subtracts  four  from  the  OAB, 
takes  the  absolute  value  of  the  result,  and  adds  to  it  the  random  uniform  draw. 
The  result  is  then  multiplied  by  the  probability  factor.  This  gives  a  resulting 
probability  that  will  always  be  between  0  and  1 .  The  purpose  of  the  equation  is  to 
give  a  range  of  probabilities  for  the  player  to  access,  and  for  the  probabilities  to 
be  decreasingly  lower  as  the  OAB  value  increases.  For  instance,  if  the  probability 
factor  is  0.2,  a  player  with  an  OAB  of  0  will  have  a  behavior  probability  between 
0.8  and  1.  Likewise,  a  player  with  an  OAB  of  4  will  have  a  behavior  probability 
between  0  and  0.2.  In  both  cases,  a  separate  random  uniform  draw  is  compared 
to  the  probability  range. 
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j°{ Green  player  reneges  from  or  is  a  no-show  lo  a  KLE.  or 
Blue  player  offers  threat  during  KLE} 

= i\OAS -4|+E7)*£/ 

where  0.45  =  observed  attitude  and  behavior,  between  0  and  4 
U~Unifonn( 0,1) 

pf  =  probability  factor  between  0  and  0.2 
Figure  2.  Behavior  Equation  2 

Behavior  Equation  3  (Figure  3)  is  used  to  see  if  a  Green  player  is  going  to 
be  captured  or  killed  by  a  Blue  player  following  a  campaign  or  captured  or  killed 
by  a  Red  player  following  a  KLE  or  campaign.  It  has  two  variables.  The  first 
represents  a  baseline  probability.  The  second  represents  some  amount  of 
elapsed  time  between  two  events.  The  equation  multiplies  the  baseline 
probability  by  the  time.  The  KLE  Model  assumes  that  the  resulting  calculation  will 
always  be  less  than  or  equal  to  one  to  make  it  a  valid  probability,  so  maximum 
times  between  events  need  to  be  planned  accordingly.  The  purpose  of  the 
equation  is  to  give  an  increasing  behavior  probability  as  a  player  spends  more 
time  performing  some  action.  For  instance,  if  the  baseline  probability  is  0.2  and  a 
player  spends  2  units  of  time  in  an  activity,  the  player  will  have  a  behavior 
probability  of  0.4.  Then,  a  random  uniform  draw  is  compared  to  the  probability. 

2*  {Green  player  is  captured  or  tilled  by  Blue  Player  after  a  c  ampaign  or 
by  Red  player  after  a  KLE  or  campaign} 

= 

where  d.  „...  =  baseline  probability  between  0  and  l 
rimc=  elapsed  time  between  events 

Figure  3.  Behavior  Equation  3 


16 


Behavior  Equation  4  (Figure  4)  is  used  to  see  if  a  Green  player  is  going  to 
be  captured  or  killed  by  a  Blue  player  following  a  KLE.  It  has  two  variables.  The 
first  represents  a  baseline  probability.  The  second  represents  some  amount  of 
elapsed  time  between  two  events.  The  equation  divides  the  baseline  probability 
by  the  time.  The  KLE  Model  assumes  that  the  resulting  calculation  will  always  be 
less  than  or  equal  to  one  to  make  it  a  valid  probability,  so  minimum  and 
maximum  times  between  events  need  to  be  planned  accordingly.  The  purpose  of 
the  equation  is  to  give  a  decreasing  behavior  probability  as  a  player  spends  more 
time  performing  some  action.  For  instance,  if  the  baseline  probability  is  0.3  and  a 
player  spends  3  units  of  time  in  an  activity,  the  player  will  have  a  behavior 
probability  of  0.1 .  Then,  a  random  uniform  draw  is  compared  to  the  probability. 

i*  {Green  player  is  captured  or  killed  by  Blue  Player  after  a  KLE  } 

P ■l.liXt.' !. 

lime 

where  j ?, _ ^  =  baseline  probability  between  0  and  1 

lime  =  elapsed  time  between  events 

Figure  4.  Behavior  Equation  4 

Behavior  Equation  5  (Figure  5),  which  is  actually  a  five-by-five  probability 
transition  matrix,  is  used  to  see  if  a  Green  player  updates  his  OAB  during  a  KLE 
or  after  being  captured,  or  it  is  used  to  set  the  OAB  of  a  replacement  after  a 
Green  player  is  captured  or  killed.  The  equation  has  three  variables.  The  first 
represents  the  OAB  value,  an  integer  between  0  and  4,  of  a  player.  The  second 
represents  the  probability  of  an  OAB  decrease.  The  third  represents  the 
probability  of  an  OAB  increase.  The  model  uses  the  two  probabilities  to  complete 
the  matrix  in  Figure  5.  For  example,  if  the  decrease  probability  is  0.1,  the 
increase  probability  is  0.2,  and  the  player  OAB  is  3,  then  the  player  will  have  a 
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0.1  probability  of  lowering  his  OAB  to  2,  a  0.7  probability  of  keeping  his  OAB  at  3, 
and  a  0.2  probability  of  raising  his  OAB  to  4.  We  assume  that  the  Green  player’s 
OAB  will  change  by  at  most  1  (in  either  direction)  after  a  KLE. 
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where  045  =  observed  attitude  and  behavior 

D  =  probability  of  GAB  decrease 

I 

=  probability  of  OAB  increase 

Figure  5.  Behavior  Equation  5  probability  transition  matrix 

D.  COMPONENTS  OF  KLE  MODEL 
1 .  CreatePlayers 

The  CreatePlayers  component  creates  a  number  of  BluePlayer  agents 
and  GreenPlayer  agents,  each  defined  by  the  user  via  input  parameters  NBp  and 
A/gp,  respectively,  which  will  be  used  in  the  KLE  Model.  BluePlayer  agents 
require  a  parameter  p/  that  gives  their  probability  of  having  an  incentive  to  offer. 
GreenPlayer  agents  require  four  parameters,  pc,  Pklk,  Ptk,  and  pRK,  which  give 
probabilities  for  being  corrupt,  having  key  leader  critical  knowledge,  having  threat 
critical  knowledge,  and  having  resource  critical  knowledge,  respectively. 

Parameters  for  the  CreatePlayers  component  are  summarized  in  Table  3. 
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Parameter 

Description 

Nbp 

total  number  of  Blue  players 

Pi 

probability  of  Blue  player  having  incentive  to  offer 

Nqp 

total  number  of  Green  players 

Pc 

probability  of  Green  player  being  corrupt 

Pklk 

probability  of  Green  player  having  key  leader  knowledge 

Ptk 

probability  of  Green  player  having  threat  knowledge 

Prk 

probability  of  Green  player  having  resource  knowledge 

Table  3.  CreatePlayers  parameters 

The  event  graph  for  the  CreatePlayers  component  is  shown  in  Figure  6 


(  Run 

0  ^Nbp) 

f  1  i 

/  Create  \  X  Blue  \ 

(  Blue  \  Player  \ 

Player  J  by  Arrival  J 

{BluePlayer  b  = 

/  new  BluePlayer(p,) 

i++} 

V  {GreenPlayer  g  = 

N.  new  GreenPlayer( "GREEN",  pc,  pKLK,  p^,  pRK) 

i++>- — ^  ^ 

n.  f  Create  \  /  Green  \ 

Green  \  Player  \ 

y  Player  I  g  y  Arrival  J 

Vo \j^y 

\  j  i 

(i  <  Ngp) 

Figure  6.  CreatePlayers  event  graph 
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The  Run  event  schedules  the  CreateBluePlayer  and  CreateGreenPlayer 
events,  passing  the  local  parameter  zero  to  both. 

The  CreateBluePlayer  and  CreateGreenPlayer  events  simulate  adding  a 
Blue  player  or  Green  player,  respectively,  to  the  model.  They  each  take  in  a  local 
integer  parameter  to  keep  track  of  how  many  players  have  been  created.  Each 
event  creates  a  BluePlayer  or  GreenPlayer  agent,  respectively,  increments  the 
local  integer  parameter  by  one,  and  schedules  a  BluePlayerArrival  or 
GreenPlayerArrival  event,  respectively,  passing  along  the  created  agent.  The 
self-scheduling  loops  schedule  another  agent  creation  if  the  local  integer  variable 
is  less  than  the  parameters  NBp  or  NGp,  respectively. 

The  BluePlayerArrival  and  GreenPlayerArrival  events  each  simulate  a 
Blue  player  or  Green  player,  respectively,  looking  to  schedule  their  first  KLE. 
They  take  in  a  local  parameter  represented  by  a  BluePlayer  or  GreenPlayer 
agent,  respectively. 

2.  HandleEngagementType 

The  HandleEngagementType  component  handles  the  scheduling  of  micro- 
KLEs  and  KLEs.  It  has  six  input  parameters.  It  requires  four  random  distributions 
representing  the  stream  of  times  that  Blue  players  schedule  their  next  micro-KLE 
({Inm}),  the  stream  of  times  that  Blue  Players  schedule  their  next  KLE  ({t/wc}),  the 
stream  of  times  that  Green  players  renege  from  a  KLE  ({tRG}),  and  the  stream  of 
times  that  Blue  players  schedule  their  next  arrival  for  another  micro-KLE  or  KLE 
{{Ibm})-  The  parameter  pfRG,  which  is  a  number  between  0  and  0.2,  is  used  as  a 
probability  factor  to  calculate  whether  a  Green  player  is  going  to  renege  from  a 
KLE.  The  parameter  pf/vs,  which  is  a  number  between  0  and  0.2,  is  used  as  a 
probability  factor  to  calculate  whether  a  Green  player  is  a  no-show  to  a  KLE. 

The  HandleEngagementType  component  has  two  state  variables  that 
represent  lists;  q  is  a  queue  to  hold  the  arriving  Green  players  to  the  component, 
and  x  is  a  list  of  any  Green  players  that  have  been  canceled  and  no  longer 
needed  in  the  model. 


20 


Parameters,  parameter  constraints,  and  state  variables  for  the 
HandleEngagementType  component  are  summarized  in  Table  4. 


Parameter 

Description 

{I-nm) 

stream  of  Blue  player  next  micro-KLE  times 

{W 

stream  of  Blue  player  next  KLE  times 

{tRG} 

stream  of  Green  player  renege  times 

{tBIVl} 

stream  of  Blue  player  next  meeting  times 

pff?G 

renege  probability  factor 

P^NS 

no-show  probability  factor 

Parameter  Constraint 

0  <  pfRG  <  0.2 

0  <  pfNS  <  0.2 

State  Variable 

Description 

q 

queue  to  hold  arriving  Green  players 

X 

list  of  canceled  Green  players 

Table  4.  HandleEngagementType  parameters,  parameter  constraints,  and 

state  variables 


The  event  graph  for  the  HandleEngagementType  component  is  shown  in 
Figure  7. 
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The  Run  event  clears  q  and  x. 
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The  BluePlayerArrival  event  simulates  a  Blue  player  looking  for  a  micro- 
KLE  or  looking  to  set  up  a  KLE.  It  takes  a  BluePlayer  agent  as  its  local 
parameter.  If  there  are  no  Green  players  to  meet,  a  BlueReadyForMicroKLE 
event  is  scheduled  with  a  time  delay  pulled  from  {Inm},  passing  along  the  local 
Blue  player.  If  there  is  a  Green  player  available,  a  LinkPlayersForKLE  event  is 
scheduled,  passing  along  the  local  Blue  player. 

The  GreenPlayerArrival  event  simulates  a  Green  player  looking  to  set  up  a 
KLE.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It  adds  the  local  Green 
player  to  q. 

The  BlueReadyForMicroKLE  event  simulates  a  Blue  player  being  ready  to 
start  a  micro-KLE.  It  takes  a  BluePlayer  agent  as  its  local  parameter. 

The  LinkPlayersForKLE  event  simulates  the  initial  agreement  by  a  Blue 
player  and  Green  player  to  set  up  a  KLE.  It  takes  a  BluePlayer  agent  as  its  local 
parameter.  Since  the  model  assumes  Blue  players  have  no  preference  for  which 
Green  player  they  engage,  it  removes  the  first  Green  player  from  q  and  assigns  it 
to  a  local  GreenPlayer  agent  variable.  It  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Green  player 
reneges  by  using  the  Green  player’s  OAB  value  and  the  parameter  pfRG  in 
behavior  Equation  2  (Figure  2).  If  the  random  uniform  draw  is  less  than  the 
calculated  renege  probability,  it  schedules  a  GreenReneges  event  with  a  time 
delay  pulled  from  {tRG},  passing  along  the  local  Blue  player  and  local  Green 
player.  If  the  random  uniform  draw  is  greater  than  or  equal  to  the  calculated 
renege  probability,  it  schedules  a  PlayersReadyForKLE  event  with  a  time  delay 
pulled  from  {tNK},  passing  along  the  local  Blue  player  and  local  Green  player. 

The  GreenReneges  event  simulates  a  Green  player  calling  off  a  planned 
KLE.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  If 
the  local  Green  player  is  not  in  x,  it  adds  the  Green  player  back  to  q.  If  the  Green 
player  is  not  canceled,  the  assumption  is  that  the  Green  player  is  still  alive  and 
has  reneged.  If  the  Green  player  is  canceled,  the  assumption  is  that  the  Green 
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player  is  not  alive  or  no  longer  available,  and  the  Blue  player  is  made  aware  of 
this  fact  before  showing  up  for  the  KLE.  This  event  schedules  a  BluePlayerArrival 
event  with  a  time  delay  pulled  from  {few},  passing  along  the  local  Blue  player. 

The  PlayersReadyForKLE  event  checks  if  a  Blue  player  and  Green  player 
are  ready  to  start  a  KLE.  It  takes  both  a  BluePlayer  and  Green  Player  agent  as  its 
local  parameters.  It  draws  a  random  uniform  number  between  0  and  1.  It  then 
calculates  the  probability  that  the  local  Green  player  is  a  no-show  by  using  the 
Green  player’s  OAB  value  and  the  parameter  pfNS  in  behavior  Equation  2  (Figure 
2).  If  the  local  Green  player  is  in  x,  or  if  the  random  uniform  draw  is  less  than  the 
calculated  no-show  probability,  it  schedules  a  GreenNoShow  event,  passing 
along  the  local  Blue  player  and  local  Green  player.  If  the  local  Green  player  is  not 
in  x  and  the  random  uniform  draw  is  greater  than  or  equal  to  the  calculated  no- 
show  probability,  it  schedules  a  SendPlayersToKLE  event,  passing  along  the 
local  Blue  player  and  local  Green  player. 

The  GreenNoShow  event  simulates  a  Green  player  not  showing  up  for  a 
KLE.  It  takes  both  a  BluePlayer  and  Green  Player  agent  as  its  local  parameters.  If 
the  local  Green  player  is  not  in  x,  it  adds  the  Green  player  back  to  q.  If  the  Green 
player  is  not  canceled,  the  assumption  is  that  the  Green  player  is  still  alive  and  is 
a  no-show.  If  the  Green  player  is  canceled,  the  assumption  is  that  the  Green 
player  is  not  alive  or  no  longer  available,  and  the  Blue  player  is  made  aware  of 
this  fact  upon  showing  up  for  the  KLE.  This  event  schedules  a  BluePlayerArrival 
event  with  a  time  delay  pulled  from  {Ibm},  passing  along  the  local  Blue  player. 

The  SendPlayersToKLE  event  simulates  a  Blue  player  and  Green  player 
being  ready  to  start  a  KLE.  It  takes  both  a  BluePlayer  and  Green  Player  agent  as 
its  local  parameters. 

The  GreenCanceled  event  simulates  a  Green  player  who  is  a  replacement 
being  no  longer  needed  in  the  model.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter.  It  removes  the  local  Green  player  from  q,  and  it  adds  the  player  to  x. 
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3.  MicroKeyLeaderEngagement 

The  MicroKeyLeaderEngagement  component  represents  a  micro-KLE 
with  an  entity  that  is  not  a  key  leader.  It  has  two  input  parameters.  It  requires  a 
random  distribution  representing  the  stream  of  times  that  Blue  players  will  spend 
in  a  micro-KLE  ({fM}).  The  parameter  pfCK,  which  is  a  number  between  0  and  0.2, 
is  used  as  a  probability  factor  to  calculate  whether  a  Blue  player  is  going  to  gain 
critical  knowledge  during  a  micro-KLE. 

The  MicroKeyLeaderEngagement  component  has  two  state  variables.  The 
variable  Nmkle  tracks  the  number  of  micro-KLEs  held.  The  variable  NTkg  tracks 
the  number  of  times  critical  knowledge  is  gained  from  a  micro-KLE. 


Parameters,  parameter  constraints,  and  state  variables  for  the 
MicroKeyLeaderEngagement  component  are  summarized  in  Table  5. 


Parameter 

Description 

{tNl} 

stream  of  micro-KLE  times 

PfcK 

chance  of  knowledge  probability  factor 

Parameter  Constraint 

0  ^  pfcK  ^  0.2 

State  Variable 

Description 

Nmkle 

number  of  micro-KLEs  (initialized  to  0) 

Ntkg 

number  of  times  critical  knowledge  gained  (initialized  to  0) 

Table  5.  MicroKeyLeaderEngagement  parameters,  parameter  constraints, 

and  state  variables 


The  event  graph  for  the  MicroKeyLeaderEngagement  component  is 
shown  in  Figure  8. 
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{{U}  ~  U(0,1) 

{l}~  lnteger(0,4) 

double  p  =  behaviorEquationl(l,  pfCK)} 


{nmkle++} 


Figure  8.  MicroKeyLeaderEngagement  event  graph 


The  Run  event  initializes  the  two  state  variables  to  zero. 

The  StartMicroKLE  event  simulates  the  beginning  of  a  micro-KLE.  It  takes 
a  BluePlayer  agent  as  its  local  parameter.  It  draws  a  random  uniform  number 
between  0  and  1.  It  also  draws  a  random  integer  between  0  and  4  that 
represents  the  OAB  of  the  non-key  leader.  It  then  calculates  the  probability  that 
the  non-key  leader  honors  the  local  Blue  player’s  critical  knowledge  request  by 
using  the  random  integer  draw  and  the  parameter  pfCK  in  behavior  Equation  1 
(Figure  1).  If  the  random  uniform  draw  is  less  than  the  calculated  knowledge 
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probability,  it  schedules  an  EndMicroKLEAndGetKnowledge  event  with  a  time 
delay  pulled  from  {fw},  passing  along  the  local  Blue  player.  If  the  random  uniform 
draw  is  greater  than  or  equal  to  the  calculated  knowledge  probability,  it 
schedules  an  EndMicroKLEAndDoNotGetKnowledge  event  with  the  same  time 
delay  and  by  passing  the  Blue  player. 

The  EndMicroKLEAndGetKnowledge  event  simulates  the  end  of  a  micro- 
KLE  and  a  Blue  player  getting  critical  knowledge.  It  takes  a  BluePlayer  agent  as 
its  local  parameter.  It  increments  NMkle  and  NTkg  both  by  one.  It  then  schedules 
a  ScheduleBlueNextMeeting  event,  passing  along  the  local  Blue  player. 

The  EndMicroKLEAndDoNotGetKnowledge  event  simulates  the  end  of  a 
micro-KLE  and  a  Blue  player  not  getting  any  critical  knowledge.  It  takes  a 
BluePlayer  agent  as  its  local  parameter.  It  increments  NMkle  by  one.  It  then 
schedules  a  ScheduleBlueNextMeeting,  passing  along  the  local  Blue  player. 

The  ScheduleBlueNextMeeting  event  simulates  a  Blue  player  scheduling 
his  next  arrival  for  a  micro-KLE  or  KLE.  It  takes  a  BluePlayer  agent  as  its  local 
parameter. 

4.  KeyLeaderEngagement 

The  KeyLeaderEngagement  component  represents  a  KLE  occurrence.  It 
has  three  input  parameters.  It  requires  two  random  distributions  representing  the 
stream  of  times  that  Blue  players  and  Green  players  will  spend  in  a  KLE  ({fo}) 
and  the  stream  of  times  that  Blue  players  schedule  their  next  arrival  for  another 
micro-KLE  or  KLE  ({few})-  The  parameter  p/  is  the  same  parameter  from  the 
CreatePlayers  component  representing  the  probability  that  a  Blue  player  has  an 
incentive  to  offer. 

The  KeyLeaderEngagement  component  has  two  state  variables.  The 
variable  NKle  tracks  the  number  of  KLEs  held.  The  variable  x  is  a  list  of  any 
Green  players  that  have  been  canceled  and  no  longer  needed  in  the  model. 
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Parameters  and  state  variables  for  the  KeyLeaderEngagement  component 
are  summarized  in  Table  6. 


Parameter 

Description 

{tK} 

stream  of  KLE  times 

Ubm} 

stream  of  Blue  player  next  meeting  times 

Pi 

probability  of  Blue  player  having  incentive  to  offer 

State  Variable 

Description 

Nkle 

number  of  KLEs  (initialized  to  0) 

X 

list  of  canceled  Green  players 

Table  6. 

KeyLeaderEngagement  parameters  and  state  variables 

The  event  graph  for  the  KeyLeaderEngagement  component  is  shown  in 
Figure  9. 


fNKL£++ 

g.stampKleEndTime() 
if  (x.contains(g))  {g.setKilled(2)}} 


Figure  9.  KeyLeaderEngagement  event  graph 
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The  Run  event  initializes  NkleIo  zero.  It  also  clears  x. 

The  StartKLE  event  simulates  the  beginning  of  a  KLE.  It  takes  both  a 
BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  It  stamps  the  KLE 
start  time  for  the  local  Green  player.  It  resets  whether  the  local  Blue  player  has 
an  incentive  to  offer  using  p/.  Lastly,  it  schedules  an  EndKLE  event  with  a  time 
delay  pulled  from  {tK},  passing  along  the  local  Blue  player  and  local  Green  player. 

The  EndKLE  event  simulates  the  end  of  a  KLE.  It  takes  both  a  BluePlayer 
and  GreenPlayer  agent  as  its  local  parameters.  It  increments  NKle  by  one, 
stamps  the  KLE  end  time  for  the  local  Green  player,  and,  if  the  local  Green 
player  is  in  x,  sets  the  killed  status  of  the  local  Green  player  as  if  he  was  killed  by 
a  Red  player.  This  event  schedules  a  ScheduleBlueNextMeeting  event  with  a 
time  delay  pulled  from  {few},  passing  along  the  local  Blue  player.  It  also 
schedules  a  HandleRequests  event,  passing  along  the  local  Blue  player  and 
local  Green  player. 

The  ScheduleBlueNextMeeting  event  simulates  a  Blue  player  scheduling 
his  next  arrival  for  a  micro-KLE  or  KLE.  It  takes  a  BluePlayer  agent  as  its  local 
parameter. 

The  HandleRequests  event  simulates  a  Blue  player  and  Green  player 
going  over  the  KLE  requests.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent 
as  its  local  parameters. 

The  GreenCanceled  event  simulates  a  Green  player  replacement  who  is 
no  longer  needed  in  the  model.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter.  It  adds  the  local  Green  player  to  x. 

5.  HandleMessageRequest 

The  HandleMessageRequest  component  represents  a  GreenPlayer  agent 
deciding  if  he  will  pass  a  message  from  a  BluePlayer  agent  to  those  under  his 
influence.  It  has  four  input  parameters.  The  parameter  pfBr,  which  is  a  number 
between  0  and  0.2,  is  used  as  a  probability  factor  to  calculate  whether  a  Blue 
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player  will  offer  a  threat  during  a  KLE  to  get  the  Green  player  to  pass  a  message. 
The  final  three  parameters,  pfHR,  pfHRi,  and  pfHRT,  all  between  0  and  0.2,  are  used 
as  probability  factors  to  calculate  whether  a  Green  player  will  honor  the  Blue 
player’s  request  outright,  honor  with  an  incentive,  or  honor  with  a  threat, 
respectively. 

The  HandleMessageRequest  component  has  one  state  variable.  The 
variable  NHrm  tracks  the  number  of  honored  message  requests. 


Parameters,  parameter  constraints,  and  state  variables  for  the 
HandleMessageRequest  component  are  summarized  in  Table  7. 


Parameter 

Description 

pf(5T 

Blue  player  offering  threat  probability  factor 

Pf|HR 

honor  request  probability  factor 

P^HRI 

honor  request  with  incentive  probability  factor 

P^HRT 

honor  request  with  threat  probability  factor 

Parameter  Constraint 

0  <  pfBT  <  0.2 

0  -  P^HR  -  0.2 

0  -  Pf|HRI  -  0.2 

0  ^  pfHRT  ^  0.2 

State  Variable 

Description 

Nhrm 

number  of  honored  message  requests  (initialized  to  0) 

Table  7.  HandleMessageRequest  parameters,  parameter  constraints,  and 

state  variables 

The  event  graph  for  the  HandleMessageRequest  component  is  shown  in 
Figures  10  and  1 1 . 
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Figure  10.  HandleMessageRequest  event  graph  (part  1) 


31 


A 

{g.setAgreedToPassMessage(false) 

{UJ  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab();  pfHR)} 

B 

{g.setlncentivized(true) 

{U2}  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHRI)} 

C 

{g.setThreatened(true) 

{U3}  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHRT)}} 

Figure  1 1 .  HandleMessageRequest  event  graph  (part  2) 

The  Run  event  initializes  Nhrm  to  zero. 

The  StartMessageRequest  event  simulates  the  beginning  of  the  message 
request.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as  its  local 
parameters.  It  resets  the  fact  that  the  local  Green  player  has  agreed  to  pass  a 
message  to  false.  Next,  it  draws  a  random  uniform  number  between  0  and  1 .  It 
then  calculates  the  probability  that  the  local  Green  player  will  honor  the  request 
outright  to  pass  a  message  by  using  the  Green  player’s  OAB  value  and  the 
parameter  pfHR  in  behavior  Equation  1  (Figure  1 ).  If  the  random  uniform  draw  is 
less  than  the  calculated  honoring  request  probability,  it  schedules  an 
AgreeToPassMessage  event,  passing  along  the  local  Blue  player  and  local 
Green  player.  If  the  random  uniform  draw  is  greater  than  or  equal  to  the 
calculated  honoring  request  probability,  it  schedules  a  DoNotPassOfferlncentive 
event,  passing  along  the  local  Blue  player  and  local  Green  player. 

The  AgreeToPassMessage  event  simulates  a  Green  player  agreeing  to 
pass  a  message.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as  its  local 
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parameters.  It  increments  Nhrm  by  one,  and  it  sets  the  fact  that  the  local  Green 
player  has  agreed  to  pass  a  message  to  true.  It  schedules  an 
EndMessageRequest  event,  passing  along  the  local  Blue  player  and  local  Green 
player. 

The  DoNotPassOfferlncentive  event  simulates  a  Green  player  deciding 
not  to  pass  a  message  and  a  Blue  player  potentially  offering  an  incentive  to 
persuade  the  Green  player  to  change  his  mind  and  pass  a  message.  It  takes 
both  a  BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  If  the  local 
Blue  player  has  an  incentive  to  offer  to  the  local  Green  player,  it  schedules  an 
IncentiveOffered  event,  passing  along  the  local  Blue  player  and  local  Green 
player.  If  the  local  Blue  player  does  not  have  an  incentive  to  offer,  it  schedules  a 
DoNotPassPresentThreat  event,  passing  along  the  local  Blue  player  and  local 
Green  player. 

The  IncentiveOffered  event  simulates  a  Blue  player  offering  an  incentive 
to  a  Green  player  to  persuade  him  to  pass  a  message.  It  takes  both  a  BluePlayer 
and  GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact  that  the  local 
Green  player  has  been  incentivized  to  true.  Next,  it  draws  a  random  uniform 
number  between  0  and  1.  It  then  calculates  the  probability  that  the  local  Green 
player  will  honor  the  request  to  pass  a  message  given  an  incentive  by  using  the 
Green  player’s  OAB  value  and  the  parameter  pfHRi  in  behavior  Equation  1  (Figure 
1).  If  the  Green  player  is  corrupt  and  the  random  uniform  draw  is  less  than  the 
calculated  honoring  request  probability,  it  schedules  an  AgreeToPassMessage 
event,  passing  along  the  local  Blue  player  and  local  Green  player.  If  the  Green 
player  is  corrupt  and  the  random  uniform  draw  is  greater  than  or  equal  to  the 
calculated  honoring  request  probability,  or  if  the  Green  player  is  not  corrupt,  it 
schedules  a  DoNotPassPresentThreat  event,  passing  along  the  local  Blue  player 
and  local  Green  player. 

The  DoNotPassPresentThreat  event  simulates  a  Green  player  deciding 

not  to  pass  a  message  and  a  Blue  player  potentially  presenting  a  threat  to 

persuade  the  Green  player  to  change  his  mind  and  pass  a  message.  It  takes 
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both  a  BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  It  draws  a 
random  uniform  number  between  0  and  1.  It  then  calculates  the  probability  that 
the  local  Blue  player  will  threaten  the  local  Green  player  by  using  the  Green 
player’s  OAB  value  and  the  parameter  pfBr  in  behavior  Equation  2  (Figure  2).  If 
the  random  uniform  draw  is  less  than  the  calculated  threat  probability,  it 
schedules  a  ThreatPresented  event,  passing  along  the  local  Blue  player  and 
local  Green  player.  If  the  random  uniform  draw  is  greater  than  or  equal  to  the 
calculated  threat  probability,  it  schedules  a  DoNotAgreeToPassMessage  event, 
passing  along  the  local  Blue  player  and  local  Green  player. 

The  ThreatPresented  event  simulates  a  Blue  player  threatening  a  Green 
player  to  persuade  him  to  pass  a  message.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact  that  the  local  Green 
player  has  been  threatened  to  true.  Next,  it  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Green  player  will 
honor  the  request  to  pass  a  message  given  a  threat  by  using  the  Green  player’s 
OAB  value  and  the  parameter  pfHRT  in  behavior  Equation  1  (Figure  1).  If  the 
random  uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it 
schedules  an  AgreeToPassMessage  event,  passing  along  the  local  Blue  player 
and  local  Green  player.  If  the  random  uniform  draw  is  greater  than  or  equal  to  the 
calculated  honoring  request  probability,  it  schedules  a 
DoNotAgreeToPassMessage  event,  passing  along  the  local  Blue  player  and  local 
Green  player. 

The  DoNotAgreeToPassMessage  event  simulates  a  Green  player 
ultimately  not  agreeing  to  pass  a  message.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  schedules  an  EndMessageRequest 
event,  passing  along  the  local  Blue  player  and  local  Green  player. 

The  EndMessageRequest  event  simulates  the  end  of  the  message 
request.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as  its  local 
parameters. 
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6.  HandleKeyLeaderKnowledgeRequest 

The  HandleKeyLeaderKnowledgeRequest  component  represents  a 
GreenPlayer  agent  deciding  on  whether  to  provide  key  leader  critical  knowledge 
to  a  BluePlayer.  It  has  five  input  parameters.  The  parameters  pfBr,  pfHR,  pfhiRi, 
and  pfHRT  are  the  same  as  those  used  in  the  HandleMessageRequest 
component.  The  same  parameter  constraints  apply  to  these  four  parameters. 
The  parameter  pKu<  is  the  same  parameter  from  the  CreatePlayers  component 
representing  the  probability  that  a  Green  player  has  key  leader  critical 
knowledge. 

The  HandleKeyLeaderKnowledgeRequest  component  has  one  state 
variable.  The  variable  NHrk  tracks  the  number  of  honored  key  leader  knowledge 
requests. 


Parameters,  parameter  constraints,  and  state  variables  for  the 
HandleKeyLeaderKnowledgeRequest  component  are  summarized  in  Table  8. 


Parameter 

Description 

Pf[3T 

Blue  player  offering  threat  probability  factor 

Pf  HR 

honor  request  probability  factor 

P^HRI 

honor  request  with  incentive  probability  factor 

P^RT 

honor  request  with  threat  probability  factor 

Pklk 

probability  of  Green  player  having  key  leader  knowledge 

Parameter  Constraint 

0  <  pfBT  <  0.2 

0  <  pfHR  <  0.2 

0  ^  PfHRI  ^  0.2 

0  ^  pfHRT  ^  0.2 

State  Variable 

Description 

Nhrk 

number  of  honored  key  leader  knowledge  requests  (initialized  to  0) 

Table  8.  HandleKeyLeaderKnowledgeRequest  parameters,  parameter 

constraints,  and  state  variables 

The  event  graph  for  the  HandleKeyLeaderKnowledgeRequest  component 
is  shown  in  Figures  12  and  13. 
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Figure  12.  HandleKeyLeaderKnowledgeRequest  event  graph  (part  1) 
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A 

{{UJ  ~  u(o,i) 

double  p  =  behaviorEquationl(g.getOab(),  pfHR)} 

B 

{g.setlncentivized(true) 

{U2}  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHm)}} 

C 

{g.setThreatened(true) 

{U3}~U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHRT)}} 


Figure  13.  HandleKeyLeaderKnowledgeRequest  event  graph  (part  2) 

The  Run  event  initializes  Nhrk^o  zero. 

The  StartKeyLeaderKnowledgeRequest  event  simulates  the  beginning  of 
the  key  leader  critical  knowledge  request.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Green  player  will 
honor  the  request  outright  to  provide  key  leader  critical  knowledge  by  using  the 
Green  player’s  OAB  value  and  the  parameter  pfHR  in  behavior  Equation  1  (Figure 
1 ).  If  the  local  Green  player  does  not  have  any  key  leader  critical  knowledge,  it 
schedules  a  KnowsNothingKeyLeader  event,  passing  along  the  local  Blue  player 
and  local  Green  player.  If  the  Green  player  has  key  leader  knowledge  and  the 
random  uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it 
schedules  a  ProvideKeyLeaderKnowledge  event,  passing  along  the  local  Blue 
player  and  local  Green  player.  If  the  Green  player  has  key  leader  knowledge  and 
the  random  uniform  draw  is  greater  than  or  equal  to  the  calculated  honoring 
request  probability,  it  schedules  a  DoNotProvideOfferlncentive  event,  passing 
along  the  local  Blue  player  and  local  Green  player. 
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The  KnowsNothingKeyLeader  event  simulates  a  Green  player  not  having 
any  knowledge  on  other  key  leaders.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters.  It  reinitializes  whether  the  local  Green  player  has 
key  leader  critical  knowledge  by  using  the  parameter  Pklk-  It  schedules  an 
EndKeyLeaderKnowledgeRequest  event,  passing  along  the  local  Blue  player  and 
local  Green  player. 

The  ProvideKeyLeaderKnowledge  event  simulates  a  Green  player 
providing  key  leader  critical  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  increments  Nhrk  by  one,  and  it 
resets  whether  the  local  Green  player  has  key  leader  critical  knowledge  by  using 
the  parameter  Pklk-  It  schedules  an  EndKeyLeaderKnowledgeRequest  event, 
passing  along  the  local  Blue  player  and  local  Green  player. 

The  DoNotProvideOfferlncentive  event  simulates  a  Green  player  deciding 
not  to  provide  key  leader  critical  knowledge  and  a  Blue  player  potentially  offering 
an  incentive  to  get  such  knowledge.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters.  If  the  local  Blue  player  has  an  incentive  to  offer  to 
the  local  Green  player,  it  schedules  an  IncentiveOffered  event,  passing  along  the 
local  Blue  player  and  local  Green  player.  If  the  local  Blue  player  does  not  have 
an  incentive  to  offer,  it  schedules  a  DoNotProvidePresentThreat  event,  passing 
along  the  local  Blue  player  and  local  Green  player. 

The  IncentiveOffered  event  simulates  a  Blue  player  offering  an  incentive 

to  a  Green  player  in  an  attempt  to  extract  key  leader  critical  knowledge.  It  takes 

both  a  BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact 

that  the  local  Green  player  has  been  incentivized  to  true.  Next,  it  draws  a  random 

uniform  number  between  0  and  1 .  It  then  calculates  the  probability  that  the  local 

Green  player  will  honor  the  request  to  provide  key  leader  critical  knowledge  given 

an  incentive  by  using  the  Green  player’s  OAB  value  and  the  parameter  pfHRi  in 

behavior  Equation  1  (Figure  1).  If  the  Green  player  is  corrupt  and  the  random 

uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it  schedules 

a  ProvideKeyLeaderKnowledge  event,  passing  along  the  local  Blue  player  and 
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local  Green  player.  If  the  Green  player  is  corrupt  and  the  random  uniform  draw  is 
greater  than  or  equal  to  the  calculated  honoring  request  probability,  or  if  the 
Green  player  is  not  corrupt,  it  schedules  a  DoNotProvidePresentThreat  event, 
passing  along  the  local  Blue  player  and  local  Green  player. 

The  DoNotProvidePresentThreat  event  simulates  a  Green  player  deciding 
not  to  provide  key  leader  critical  knowledge  and  a  Blue  player  potentially 
presenting  a  threat  to  get  such  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Blue  player  will 
threaten  the  local  Green  player  by  using  the  Green  player’s  OAB  value  and  the 
parameter  pfBr  in  behavior  Equation  2  (Figure  2).  If  the  random  uniform  draw  is 
less  than  the  calculated  threat  probability,  it  schedules  a  ThreatPresented  event, 
passing  along  the  local  Blue  player  and  local  Green  player.  If  the  random  uniform 
draw  is  greater  than  or  equal  to  the  calculated  threat  probability,  it  schedules  a 
DoNotProvideKeyLeaderKnowledge  event,  passing  along  the  local  Blue  player 
and  local  Green  player. 

The  ThreatPresented  event  simulates  a  Blue  player  threatening  a  Green 
player  for  key  leader  critical  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact  that  the  local  Green 
player  has  been  threatened  to  true.  Next,  it  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Green  player  will 
honor  the  request  to  provide  key  leader  critical  knowledge  given  a  threat  by  using 
the  Green  player’s  OAB  value  and  the  parameter  pfHRT  in  behavior  Equation  1 
(Figure  1).  If  the  random  uniform  draw  is  less  than  the  calculated  honoring 
request  probability,  it  schedules  a  ProvideKeyLeaderKnowledge  event,  passing 
along  the  local  Blue  player  and  local  Green  player.  If  the  random  uniform  draw  is 
greater  than  or  equal  to  the  calculated  honoring  request  probability,  it  schedules 
a  DoNotProvideKeyLeaderKnowledge  event,  passing  along  the  local  Blue  player 
and  local  Green  player. 
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The  DoNotProvideKeyLeaderKnowledge  event  simulates  a  Green  player 
ultimately  not  providing  key  leader  critical  knowledge.  It  takes  both  a  BluePlayer 
and  GreenPlayer  agent  as  its  local  parameters.  It  resets  whether  the  local  Green 
player  has  key  leader  critical  knowledge  by  using  the  parameter  pKLK ■  It  then 
schedules  an  EndKeyLeaderKnowledgeRequest  event,  passing  along  the  local 
Blue  player  and  local  Green  player. 

The  EndKeyLeaderKnowledgeRequest  event  simulates  the  end  of  the  key 
leader  critical  knowledge  request.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters. 

7.  HandleThreatKnowledgeRequest 

The  HandleThreatKnowledgeRequest  component  represents  a 
GreenPlayer  agent  deciding  on  whether  to  provide  threat  critical  knowledge  to  a 
BluePlayer.  It  has  five  input  parameters.  The  parameters  pfBr,  P^hr,  pfHRi,  and 
pfHRT  are  the  same  as  those  used  in  the  HandleMessageRequest  component. 
The  same  parameter  constraints  apply  to  these  four  parameters.  The  parameter 
Ptk  is  the  same  parameter  from  the  CreatePlayers  component  representing  the 
probability  that  a  Green  player  has  threat  critical  knowledge. 

The  HandleThreatKnowledgeRequest  component  has  one  state  variable. 
The  variable  NHrt  tracks  the  number  of  honored  threat  knowledge  requests. 

Parameters,  parameter  constraints,  and  state  variables  for  the 
HandleThreatKnowledgeRequest  component  are  summarized  in  Table  9. 
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Parameter 

Description 

PfBT 

Blue  player  offering  threat  probability  factor 

Pf  HR 

honor  request  probability  factor 

P^HRI 

honor  request  with  incentive  probability  factor 

pfhlRT 

honor  request  with  threat  probability  factor 

Ptk 

probability  of  Green  player  having  threat  knowledge 

Parameter  Constraint 

0  <  pfBT  <  0.2 

0  <  pfHR  <  0.2 

0  <  pf HRI  ^  0.2 

0  <  pf|HRT  ^  0.2 

State  Variable 

Description 

Nhrt 

number  of  honored  threat  knowledge  requests  (initialized  to  0) 

Table  9.  HandleThreatKnowledgeRequest  parameters,  parameter 
constraints,  and  state  variables 

The  event  graph  for  the  HandleThreatKnowledgeRequest  component  is 
shown  in  Figures  14  and  15. 
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Figure  14.  HandleThreatKnowledgeRequest  event  graph  (part  1) 
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A 

{{UJ  ~  u(o,i) 

double  p  =  behaviorEquationl(g.getOab(),  pfHR)} 

B 

{g.setlncentivized(true) 

{U2}  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHm)}} 

C 

{g.setThreatened(true) 

{U3}~U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHRT)}} 


Figure  15.  HandleThreatKnowledgeRequest  event  graph  (part  2) 

The  Run  event  initializes  Nhrt  to  zero. 

The  StartThreatKnowledgeRequest  event  simulates  the  beginning  of  the 
threat  critical  knowledge  request.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters.  It  draws  a  random  uniform  number  between  0  and 
1 .  It  then  calculates  the  probability  that  the  local  Green  player  will  honor  the 
request  outright  to  provide  threat  critical  knowledge  by  using  the  Green  player’s 
OAB  value  and  the  parameter  pfHR  in  behavior  Equation  1  (Figure  1).  If  the  local 
Green  player  does  not  have  any  threat  critical  knowledge,  it  schedules  a 
KnowsNothingThreat  event,  passing  along  the  local  Blue  player  and  local  Green 
player.  If  the  Green  player  has  threat  knowledge  and  the  random  uniform  draw  is 
less  than  the  calculated  honoring  request  probability,  it  schedules  a 
ProvideThreatKnowledge  event,  passing  along  the  local  Blue  player  and  local 
Green  player.  If  the  Green  player  has  threat  knowledge  and  the  random  uniform 
draw  is  greater  than  or  equal  to  the  calculated  honoring  request  probability,  it 
schedules  a  DoNotProvideOfferlncentive  event,  passing  along  the  local  Blue 
player  and  local  Green  player. 
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The  KnowsNothingThreat  event  simulates  a  Green  player  not  having  any 
knowledge  on  threats.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as  its 
local  parameters.  It  reinitializes  whether  the  local  Green  player  has  threat  critical 
knowledge  by  using  the  parameter  Ptk-  It  schedules  an 
EndThreatKnowledgeRequest  event,  passing  along  the  local  Blue  player  and 
local  Green  player. 

The  ProvideThreatKnowledge  event  simulates  a  Green  player  providing 
threat  critical  knowledge.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as  its 
local  parameters.  It  increments  Nhrt  by  one,  and  it  resets  whether  the  local 
Green  player  has  threat  critical  knowledge  by  using  the  parameter  pm-  It 
schedules  an  EndThreatKnowledgeRequest  event,  passing  along  the  local  Blue 
player  and  local  Green  player. 

The  DoNotProvideOfferlncentive  event  simulates  a  Green  player  deciding 
not  to  provide  threat  critical  knowledge  and  a  Blue  player  potentially  offering  an 
incentive  to  get  such  knowledge.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters.  If  the  local  Blue  player  has  an  incentive  to  offer  to 
the  local  Green  player,  it  schedules  an  IncentiveOffered  event,  passing  along  the 
local  Blue  player  and  local  Green  player.  If  the  local  Blue  player  does  not  have 
an  incentive  to  offer,  it  schedules  a  DoNotProvidePresentThreat  event,  passing 
along  the  local  Blue  player  and  local  Green  player. 

The  IncentiveOffered  event  simulates  a  Blue  player  offering  an  incentive 

to  a  Green  player  in  an  attempt  to  extract  threat  critical  knowledge.  It  takes  both 

a  BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact  that 

the  local  Green  player  has  been  incentivized  to  true.  Next,  it  draws  a  random 

uniform  number  between  0  and  1 .  It  then  calculates  the  probability  that  the  local 

Green  player  will  honor  the  request  to  provide  threat  critical  knowledge  given  an 

incentive  by  using  the  Green  player’s  OAB  value  and  the  parameter  pfHRi  in 

behavior  Equation  1  (Figure  1).  If  the  Green  player  is  corrupt  and  the  random 

uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it  schedules 

a  ProvideThreatKnowledge  event,  passing  along  the  local  Blue  player  and  local 
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Green  player.  If  the  Green  player  is  corrupt  and  the  random  uniform  draw  is 
greater  than  or  equal  to  the  calculated  honoring  request  probability,  or  if  the 
Green  player  is  not  corrupt,  it  schedules  a  DoNotProvidePresentThreat  event, 
passing  along  the  local  Blue  player  and  local  Green  player. 

The  DoNotProvidePresentThreat  event  simulates  a  Green  player  deciding 
not  to  provide  threat  critical  knowledge  and  a  Blue  player  potentially  presenting  a 
threat  to  get  such  knowledge.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent 
as  its  local  parameters.  It  draws  a  random  uniform  number  between  0  and  1 .  It 
then  calculates  the  probability  that  the  local  Blue  player  will  threaten  the  local 
Green  player  by  using  the  Green  player’s  OAB  value  and  the  parameter  pfar  in 
behavior  Equation  2  (Figure  2).  If  the  random  uniform  draw  is  less  than  the 
calculated  threat  probability,  it  schedules  a  ThreatPresented  event,  passing 
along  the  local  Blue  player  and  local  Green  player.  If  the  random  uniform  draw  is 
greater  than  or  equal  to  the  calculated  threat  probability,  it  schedules  a 
DoNotProvideThreatKnowledge  event,  passing  along  the  local  Blue  player  and 
local  Green  player. 

The  ThreatPresented  event  simulates  a  Blue  player  threatening  a  Green 
player  for  threat  critical  knowledge.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters.  It  sets  the  fact  that  the  local  Green  player  has  been 
threatened  to  true.  Next,  it  draws  a  random  uniform  number  between  0  and  1 .  It 
then  calculates  the  probability  that  the  local  Green  player  will  honor  the  request 
to  provide  threat  critical  knowledge  given  a  threat  by  using  the  Green  player’s 
OAB  and  the  parameter  pfHRT  in  behavior  Equation  1  (Figure  1 ).  If  the  random 
uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it  schedules 
a  ProvideThreatKnowledge  event,  passing  along  the  local  Blue  player  and  local 
Green  player.  If  the  random  uniform  draw  is  greater  than  or  equal  to  the 
calculated  honoring  request  probability,  it  schedules  a 
DoNotProvideThreatKnowledge  event,  passing  along  the  local  Blue  player  and 
local  Green  player. 
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The  DoNotProvideThreatKnowledge  event  simulates  a  Green  player 
ultimately  not  providing  threat  critical  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  resets  whether  the  local  Green 
player  has  threat  critical  knowledge  by  using  the  parameter  Ptk-  It  then  schedules 
an  EndThreatKnowledgeRequest  event,  passing  along  the  local  Blue  player  and 
local  Green  player. 

The  EndThreatKnowledgeRequest  event  simulates  the  end  of  the  threat 
critical  knowledge  request.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent  as 
its  local  parameters. 

8.  HandleResourceKnowledgeRequest 

The  HandleResourceKnowledgeRequest  component  represents  a 
GreenPlayer  agent  deciding  on  whether  to  provide  resource  critical  knowledge  to 
a  BluePlayer.  It  has  five  input  parameters.  The  parameters  pfBr ,  P^hr,  P^hri,  and 
pfHRT  are  the  same  as  those  used  in  the  HandleMessageRequest  component. 
The  same  parameter  constraints  apply  to  these  four  parameters.  The  parameter 
Prk  is  the  same  parameter  from  the  CreatePlayers  component  representing  the 
probability  that  a  Green  player  has  resource  critical  knowledge. 

The  HandleResourceKnowledgeRequest  component  has  one  state 
variable.  The  variable  NHrr  tracks  the  number  of  honored  resource  knowledge 
requests. 

Parameters,  parameter  constraints,  and  state  variables  for  the 
HandleResourceKnowledgeRequest  component  are  summarized  in  Table  10. 
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Parameter 

Description 

pfBT 

Blue  player  offering  threat  probability  factor 

Pf  HR 

honor  request  probability  factor 

PflHRI 

honor  request  with  incentive  probability  factor 

P^HRT 

honor  request  with  threat  probability  factor 

Prk 

probability  of  Green  player  having  resource  knowledge 

Parameter  Constraint 

0  <  pf[5T  ^  0.2 

0  <  pfHR  <  0.2 

0  ^  pf|HRI  ^  0.2 

0  <  pfHRT  ^  0.2 

State  Variable 

Description 

Nhrr 

number  of  honored  resource  knowledge  requests  (initialized  to  0) 

Table  10.  HandleResourceKnowledgeRequest  parameters,  parameter 

constraints,  and  state  variables 

The  event  graph  for  the  HandleResourceKnowledgeRequest  component 
is  shown  in  Figures  16  and  17. 
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Figure  16.  HandleResourceKnowledgeRequest  event  graph  (part  1) 
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A 

{{Uj}  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pfHR)} 

B 

(g.setlncentivized(true) 

{U2}  ~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab()/  pfHm)}} 

C 

{g.setThreatened(true) 

{u3}~  U(0,1) 

double  p  =  behaviorEquationl(g.getOab(),  pf HrT)}} 


Figure  17.  HandleResourceKnowledgeRequest  event  graph  (part  2) 

The  Run  event  initializes  NHrr  to  zero. 

The  StartResourceKnowledgeRequest  event  simulates  the  beginning  of 
the  resource  critical  knowledge  request.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Green  player  will 
honor  the  request  outright  to  provide  resource  critical  knowledge  by  using  the 
Green  player’s  OAB  value  and  the  parameter  pfHR  in  behavior  Equation  1  (Figure 
1 ).  If  the  local  Green  player  does  not  have  any  resource  critical  knowledge,  it 
schedules  a  KnowsNothingResource  event,  passing  along  the  local  Blue  player 
and  local  Green  player.  If  the  Green  player  has  resource  knowledge  and  the 
random  uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it 
schedules  a  ProvideResourceKnowledge  event,  passing  along  the  local  Blue 
player  and  local  Green  player.  If  the  Green  player  has  resource  knowledge  and 
the  random  uniform  draw  is  greater  than  or  equal  to  the  calculated  honoring 
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request  probability,  it  schedules  a  DoNotProvideOfferlncentive  event,  passing 
along  the  local  Blue  player  and  local  Green  player. 

The  KnowsNothingResource  event  simulates  a  Green  player  not  having 
any  knowledge  on  resources.  It  takes  both  a  BluePlayer  and  GreenPlayer  agent 
as  its  local  parameters.  It  reinitializes  whether  the  local  Green  player  has 
resource  critical  knowledge  by  using  the  parameter  prk.  It  schedules  an 
EndResourceKnowledgeRequest  event,  passing  along  the  local  Green  player. 

The  ProvideResourceKnowledge  event  simulates  a  Green  player 
providing  resource  critical  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  increments  Nhrr  by  one,  and  it 
resets  whether  the  local  Green  player  has  resource  critical  knowledge  by  using 
the  parameter  pRK.  It  schedules  an  EndResourceKnowledgeRequest  event, 
passing  along  the  local  Green  player. 

The  DoNotProvideOfferlncentive  event  simulates  a  Green  player  deciding 
not  to  provide  resource  critical  knowledge  and  a  Blue  player  potentially  offering 
an  incentive  to  get  such  knowledge.  It  takes  both  a  BluePlayer  and  GreenPlayer 
agent  as  its  local  parameters.  If  the  local  Blue  player  has  an  incentive  to  offer  to 
the  local  Green  player,  it  schedules  an  Incentive  Offered  event,  passing  along  the 
local  Blue  player  and  local  Green  player.  If  the  local  Blue  player  does  not  have 
an  incentive  to  offer,  it  schedules  a  DoNotProvidePresentThreat  event,  passing 
along  the  local  Blue  player  and  local  Green  player. 

The  IncentiveOffered  event  simulates  a  Blue  player  offering  an  incentive 
to  a  Green  player  in  an  attempt  to  extract  resource  critical  knowledge.  It  takes 
both  a  BluePlayer  and  GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact 
that  the  local  Green  player  has  been  incentivized  to  true.  Next,  it  draws  a  random 
uniform  number  between  0  and  1.  It  then  calculates  the  probability  that  the  local 
Green  player  will  honor  the  request  to  provide  resource  critical  knowledge  given 
an  incentive  by  using  the  Green  player’s  OAB  value  and  the  parameter  pfHRi  in 
behavior  Equation  1  (Figure  1).  If  the  Green  player  is  corrupt  and  the  random 
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uniform  draw  is  less  than  the  calculated  honoring  request  probability,  it  schedules 
a  ProvideResourceKnowledge  event,  passing  along  the  local  Blue  player  and 
local  Green  player.  If  the  Green  player  is  corrupt  and  the  random  uniform  draw  is 
greater  than  or  equal  to  the  calculated  honoring  request  probability,  or  if  the 
Green  player  is  not  corrupt,  it  schedules  a  DoNotProvidePresentThreat  event, 
passing  along  the  local  Blue  player  and  local  Green  player. 

The  DoNotProvidePresentThreat  event  simulates  a  Green  player  deciding 
not  to  provide  resource  critical  knowledge  and  a  Blue  player  potentially 
presenting  a  threat  to  get  such  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Blue  player  will 
threaten  the  local  Green  player  by  using  the  Green  player’s  OAB  value  and  the 
parameter  pfer  in  behavior  Equation  2  (Figure  2).  If  the  random  uniform  draw  is 
less  than  the  calculated  threat  probability,  it  schedules  a  ThreatPresented  event, 
passing  along  the  local  Blue  player  and  local  Green  player.  If  the  random  uniform 
draw  is  greater  than  or  equal  to  the  calculated  threat  probability,  it  schedules  a 
DoNotProvideResourceKnowledge  event,  passing  along  the  local  Blue  player 
and  local  Green  player. 

The  ThreatPresented  event  simulates  a  Blue  player  threatening  a  Green 
player  for  resource  critical  knowledge.  It  takes  both  a  BluePlayer  and 
GreenPlayer  agent  as  its  local  parameters.  It  sets  the  fact  that  the  local  Green 
player  has  been  threatened  to  true.  Next,  it  draws  a  random  uniform  number 
between  0  and  1 .  It  then  calculates  the  probability  that  the  local  Green  player  will 
honor  the  request  to  provide  resource  critical  knowledge  given  a  threat  by  using 
the  Green  player’s  OAB  value  and  the  parameter  pfHRT  in  behavior  Equation  1 
(Figure  1).  If  the  random  uniform  draw  is  less  than  the  calculated  honoring 
request  probability,  it  schedules  a  ProvideResourceKnowledge  event,  passing 
along  the  local  Blue  player  and  local  Green  player.  If  the  random  uniform  draw  is 
greater  than  or  equal  to  the  calculated  honoring  request  probability,  it  schedules 
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a  DoNotProvideResourceKnowledge  event,  passing  along  the  local  Blue  player 
and  local  Green  player. 

The  DoNotProvideResourceKnowledge  event  simulates  a  Green  player 
ultimately  not  providing  resource  critical  knowledge.  It  takes  both  a  BluePlayer 
and  GreenPlayer  agent  as  its  local  parameters.  It  resets  whether  the  local  Green 
player  has  resource  critical  knowledge  by  using  the  parameter  Prk.  It  then 
schedules  an  EndResourceKnowledgeRequest  event,  passing  along  the  local 
Green  player. 

The  EndResourceKnowledgeRequest  event  simulates  the  end  of  the 
resource  critical  knowledge  request.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter. 

9.  UpdateOAB 

The  UpdateOAB  component  handles  the  updating  of  a  Green  player’s 
OAB  depending  on  what  happens  during  a  KLE.  It  has  eight  input  parameters. 
The  parameters  pD0  and  p/0  represent  the  probabilities  of  an  OAB  decrease  or 
increase,  respectively,  given  the  Green  player  not  being  incentivized  and  not 
being  threatened;  the  sum  of  these  two  must  be  less  than  or  equal  to  1.  The 
parameters  pDi  and  pu  represent  the  probabilities  of  an  OAB  decrease  or 
increase,  respectively,  given  the  Green  player  being  incentivized  and  not  being 
threatened;  the  sum  of  these  two  must  be  less  than  or  equal  to  1.  The 
parameters  pDT  and  piT  represent  the  probabilities  of  an  OAB  decrease  or 
increase,  respectively,  given  the  Green  player  being  threatened;  the  sum  of 
these  two  must  be  less  than  or  equal  to  1 .  The  parameters  Pbckb  and  Pbckr  are 
baseline  probabilities  of  a  Green  player  being  captured  or  killed  by  either  a  Blue 
player  or  Red  player,  respectively.  In  order  to  avoid  overlapping  probability 
ranges,  one  minus  Pbckr  times  the  maximum  possible  KLE  time  must  be  greater 
than  or  equal  to  Pbckb- 

Parameters  and  parameter  constraints  for  the  UpdateOAB  component  are 
summarized  in  Table  1 1 . 
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Parameter 

Description 

Pdo 

probability  of  OAB  decrease  when  Green  player  not  incentivized 

and  not  threatened 

Pio 

probability  of  OAB  increase  when  Green  player  not  incentivized 

and  not  threatened 

Pdi 

probability  of  OAB  decrease  when  Green  player  incentivized  and 

not  threatened 

Pm 

probability  of  OAB  increase  when  Green  player  incentivized  and 

not  threatened 

Pdt 

probability  of  OAB  decrease  when  Green  player  threatened 

Pit 

probability  of  OAB  increase  when  Green  player  threatened 

Pbckb 

baseline  probability  of  Green  player  captured  or  killed  by  Blue 

player 

Pbckr 

baseline  probability  of  Green  player  captured  or  killed  by  Red 

player 

Parameter  Constraint 

Pdo  +  Pio  ^  1 

Pdi  +  Pn  S  1 

Pdt  +  Pit  ^  1 

Pbckb  5  1  -  Pbckr  *  (max  KLE  time) 

Table  1 1 .  UpdateOAB  parameters  and  parameter  constraints 
The  event  graph  for  the  UpdateOAB  component  is  shown  in  Figure  18. 
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Figure  18.  UpdateOAB  event  graph 


The  CheckGreenStatus  event  checks  if  a  Green  player  is  still  in  the  model 
following  a  KLE.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  If  the  local 
Green  player  has  not  been  canceled  during  a  KLE  (not  killed  in  this  case),  it 
schedules  an  OABUpdate  event,  passing  along  the  local  Green  player. 

The  OABUpdate  event  simulates  a  Green  player  changing  his  OAB  after  a 
KLE.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  If  the  Green  player  has 
not  been  incentivized  or  threatened  during  the  KLE,  it  calculates  the  Green 
player’s  new  OAB  by  using  his  current  OAB,  D  =  pD0,  and  I  =  p/0  in  behavior 
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Equation  5  (Figure  5).  If  the  Green  player  has  been  incentivized  but  not 
threatened  during  the  KLE,  it  calculates  the  Green  player’s  new  OAB  by  using  his 
current  OAB,  D  =  pD/,  and  I  =  pu  in  behavior  Equation  5  (Figure  5).  It  then  resets 
the  fact  that  the  Green  player  is  incentivized  to  false.  If  the  Green  player  has 
been  threatened  during  the  KLE,  it  calculates  the  Green  player’s  new  OAB  by 
using  his  current  OAB,  D  =  por,  and  I  =  p/r  in  behavior  Equation  5  (Figure  5).  It 
then  resets  the  facts  that  the  Green  player  is  incentivized  and  threatened  to  false. 
Lastly,  it  schedules  an  UpdateComplete  event,  passing  along  the  local  Green 
player. 

The  UpdateComplete  event  simulates  a  Green  player  completing  his  OAB 
update.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It  draws  a  random 
uniform  number  between  0  and  1 .  If  the  time  that  the  Green  player  spent  in  the 
KLE  is  greater  than  or  equal  to  one,  it  calculates  the  probability  that  he  is 
captured  or  killed  by  a  Blue  player  by  using  Pbckb  and  the  time  spent  in  the  KLE 
in  behavior  Equation  4  (Figure  4).  If  the  time  that  the  Green  player  spent  in  the 
KLE  is  less  than  one,  the  probability  of  being  captured  or  killed  by  a  Blue  player 
equals  Pbckb ■  It  also  calculates  the  probability  that  the  local  Green  player  is 
captured  or  killed  by  a  Red  player  by  using  Pbckr  and  the  time  spent  in  the  KLE 
in  behavior  Equation  3  (Figure  3).  If  the  random  uniform  draw  is  less  than  the 
calculated  capture  or  kill  by  Blue  probability,  it  schedules  a  CaptureOrKillByBlue 
event,  passing  along  the  local  Green  player.  If  the  random  uniform  draw  is 
greater  than  or  equal  to  one  minus  the  calculated  capture  or  kill  by  Red 
probability,  it  schedules  a  CaptureOrKillByRed  event,  passing  along  the  local 
Green  player.  If  the  random  uniform  draw  is  greater  than  or  equal  to  the 
calculated  capture  or  kill  by  Blue  probability  and  less  than  one  minus  the 
calculated  capture  or  kill  by  Red  probability,  it  schedules  a  Campaign  event, 
passing  along  the  local  Green  player. 

The  Campaign  event  simulates  a  Green  player  looking  to  campaign.  It 
takes  a  GreenPlayer  agent  as  its  local  parameter. 
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The  CaptureOrKillByBlue  event  simulates  a  Green  player  being  captured 
or  killed  by  a  Blue  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 

The  CaptureOrKillByRed  event  simulates  a  Green  player  being  captured 
or  killed  by  a  Red  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 

10.  Campaign 

The  Campaign  component  handles  whether  a  Green  player  will  campaign 
following  a  KLE.  It  has  five  input  parameters.  It  requires  three  random 
distributions  representing  the  stream  of  times  that  Green  players  schedule  their 
next  campaign  {{Inc}),  the  stream  of  times  that  Green  players  spend  campaigning 
({tc}),  and  the  stream  of  times  that  Green  players  schedule  their  next  arrival  for 
another  KLE  ({few})-  The  parameters  Pbckb  and  Pbckr  are  the  same  as  defined  in 
the  UpdateOAB  component.  Additional  constraints  on  these  two  parameters  are 
that  Pbckb  times  the  maximum  campaign  time  and  Pbckr  times  the  maximum 
campaign  time  both  must  be  less  than  or  equal  to  one;  this  ensures  that 
probabilities  greater  than  one  are  not  encountered. 

The  Campaign  component  has  two  state  variables.  The  variable  NPC 
tracks  the  number  of  pro-coalition  force  campaigns.  The  variable  Nac  tracks  the 
number  of  anti-coalition  force  campaigns. 

Parameters,  parameter  constraints,  and  state  variables  for  the  Campaign 
component  are  summarized  in  Table  12. 


56 


Parameter 

Description 

{tNc) 

stream  of  Green  player  next  campaign  times 

{tc} 

stream  of  Green  player  campaign  times 

{tGM} 

stream  of  Green  player  next  meeting  times 

Pbckb 

baseline  probability  of  Green  player  captured  or  killed  by  Blue 

player 

Pbckr 

baseline  probability  of  Green  player  captured  or  killed  by  Red 

player 

Parameter  Constraint 

Pbckb  *  (max  campaign  time)  <  1 

Pbckr  *  (max  campaign  time)  <  1 

State  Variable 

Description 

Npc 

number  of  pro-CF  campaigns  (initialized  to  0) 

Nac 

number  of  anti-CF  campaigns  (initialized  to  0) 

Table  12.  Campaign  parameters,  parameter  constraints,  and  state  variables 
The  event  graph  for  the  Campaign  component  is  shown  in  Figures  19  and 

20. 
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^RuT^'N-  =  0 


{int  o  =  g.getOab() 

boolean  a  =  g.hasAgreedToPassMsg() 
{U3}~  U(0,1)} 


3 


/  CaptureOrX 

/  CaptureOrX 

I  KillByRed 

KillByBlue 

V  (g)  J 

V  (8)  J 

Figure  19. 

Campaign  event  graph  (part  1 ) 
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A 

{NPC++ 

{Uj}  ~  u(o,i) 

double  c  =  behaviorEquationBfpBCKR,  g.getCampaignElapsedTime())} 

B 

^AC++ 

{U2}  ~  U(0,1) 

double  c  =  behaviorEquationSfPej-Kg,  g.getCampaignElapsedTime())} 

Figure  20.  Campaign  event  graph  (part  2) 

The  Run  event  initializes  the  two  state  variables  to  zero. 

The  CheckOAB  event  checks  a  Green  player’s  OAB  to  see  if  he  will 
campaign  or  not.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It  draws  a 
random  uniform  number  between  0  and  1.  If  the  local  Green  player  has  an  OAB 
equal  to  4,  has  an  OAB  equal  to  3  and  has  agreed  to  pass  a  message,  or  has  an 
OAB  equal  to  2,  has  agreed  to  pass  a  message,  and  the  uniform  draw  is  less 
than  0.5,  it  schedules  a  ProCFCampaign  event  with  a  time  delay  pulled  from 
{tNC},  passing  along  the  local  Green  player.  If  the  local  Green  player  has  an  OAB 
equal  to  0,  has  an  OAB  equal  to  1  and  has  agreed  to  pass  a  message,  or  has  an 
OAB  equal  to  2,  has  agreed  to  pass  a  message,  and  the  uniform  draw  is  greater 
than  or  equal  to  0.5,  it  schedules  an  AntiCFCampaign  event  with  a  time  delay 
pulled  from  {tNC},  passing  along  the  local  Green  player.  If  the  Green  player  has 
not  agreed  to  pass  a  message  and  his  OAB  equals  1,  2,  or  3,  it  schedules  a 
NoCampaign  event,  passing  along  the  local  Green  player. 

The  ProCFCampaign  event  simulates  a  Green  player  starting  his  pro¬ 
coalition  force  campaign.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It 
stamps  the  campaign  start  time  for  the  local  Green  player.  It  then  schedules  an 
EndProCFCampaign  event  with  a  time  delay  pulled  from  {tc},  passing  along  the 
local  Green  player. 
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The  AntiCFCampaign  event  simulates  a  Green  player  starting  his  anti¬ 
coalition  force  campaign.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It 
stamps  the  campaign  start  time  for  the  local  Green  player.  It  then  schedules  an 
EndAntiCFCampaign  event  with  a  time  delay  pulled  from  {tc},  passing  along  the 
local  Green  player. 

The  NoCampaign  event  simulates  a  Green  player  not  campaigning.  It 
takes  a  GreenPlayer  agent  as  its  local  parameter.  It  schedules  a 
ScheduleGreenNextMeeting  event  with  a  time  delay  pulled  from  {fGM},  passing 
along  the  local  Green  player. 

The  EndProCFCampaign  event  simulates  a  Green  player  ending  his  pro¬ 
coalition  force  campaign.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It 
increments  NPC  by  one.  It  then  draws  a  random  uniform  number  between  0  and 
1 .  It  calculates  the  probability  that  the  local  Green  player  is  captured  or  killed  by  a 
Red  player  by  using  Pbckr  and  the  time  spent  in  the  campaign  in  behavior 
Equation  3  (Figure  3).  If  the  random  uniform  draw  is  less  than  the  calculated 
capture  or  kill  by  Red  probability,  it  schedules  a  CaptureOrKillByRed  event, 
passing  along  the  local  Green  player.  If  the  random  uniform  draw  is  greater  than 
or  equal  to  the  calculated  capture  or  kill  by  Red  probability,  it  schedules  a 
ScheduleGreenNextMeeting  event  with  a  time  delay  pulled  from  {fGM},  passing 
along  the  local  Green  player. 

The  EndAntiCFCampaign  event  simulates  a  Green  player  ending  his  anti¬ 
coalition  force  campaign.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It 
increments  NAc  by  one.  It  then  draws  a  random  uniform  number  between  0  and 
1 .  It  calculates  the  probability  that  the  local  Green  player  is  captured  or  killed  by  a 
Blue  player  by  using  Pbckb  and  the  time  spent  in  the  campaign  in  behavior 
Equation  3  (Figure  3).  If  the  random  uniform  draw  is  less  than  the  calculated 
capture  or  kill  by  Blue  probability,  it  schedules  a  CaptureOrKillByBlue  event, 
passing  along  the  local  Green  player.  If  the  random  uniform  draw  is  greater  than 
or  equal  to  the  calculated  capture  or  kill  by  Blue  probability,  it  schedules  a 


60 


ScheduleGreenNextMeeting  event  with  a  time  delay  pulled  from  {fG/w}>  passing 
along  the  local  Green  player. 

The  ScheduleGreenNextMeeting  event  simulates  a  Green  player 
scheduling  his  next  arrival  for  a  KLE.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter. 

The  CaptureOrKillByRed  event  simulates  a  Green  player  being  captured 
or  killed  by  a  Red  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 

The  CaptureOrKillByBlue  event  simulates  a  Green  player  being  captured 
or  killed  by  a  Blue  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 

The  GreenCanceled  event  simulates  a  Green  player  replacement  that  is 
no  longer  needed  in  the  model.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter.  It  cancels  the  ProCFCampaign,  AntiCFCampaign, 
EndProCFCampaign,  EndAntiCFCampaign,  and  ScheduleGreenNextMeeting 
events  for  the  local  Green  player. 

11.  CaptureOrKill 

The  CaptureOrKill  component  handles  whether  a  Green  player  will  be 
captured  or  killed  by  a  Blue  player  or  Red  player  following  a  KLE  or  campaign.  It 
has  four  input  parameters.  The  parameter  pee  is  the  probability  that  a  Blue  player 
captures  a  Green  player.  One  minus  pCe  then  is  the  probability  that  a  Blue  player 
kills  him.  The  parameter  Pcr  is  the  probability  that  a  Red  player  captures  a  Green 
player.  One  minus  Pcr  then  is  the  probability  that  a  Red  player  kills  him.  The 
parameter  pDce  is  the  probability  that  a  Green  player  decreases  his  OAB  given  a 
capture  by  a  Blue  player.  The  parameter  p/CR  is  the  probability  that  a  Green 
player  increases  his  OAB  given  a  capture  by  a  Red  player. 

The  CaptureOrKill  component  has  four  state  variables.  The  variables  Nbc, 
NBk ,  Nrc,  and  NRK  track  the  number  of  Green  players  captured  by  Blue  players, 
killed  by  Blue  players,  captured  by  Red  players,  and  killed  by  Red  players, 
respectively. 


61 


Parameters  and  state  variables  for  the  CaptureOrKill  component  are 
summarized  in  Table  13. 


Parameter 

Description 

PcB 

probability  of  capture  by  Blue  player 

1  -  PCB 

probability  of  kill  by  Blue  player 

PCR 

probability  of  capture  by  Red  player 

1  -  PCR 

probability  of  kill  by  Red  player 

Pdcb 

probability  of  OAB  decrease  given  capture  by  Blue  player 

PlCR 

probability  of  OAB  increase  given  capture  by  Red  player 

State  Variable 

Description 

Nbc 

number  of  Green  player  captures  by  Blue  players  (initialized  to  0) 

Nbk 

number  of  Green  player  kills  by  Blue  players  (initialized  to  0) 

Nrc 

number  of  Green  player  captures  by  Red  players  (initialized  to  0) 

Nrk 

number  of  Green  player  kills  by  Red  players  (initialized  to  0) 

Table  13.  CaptureOrKill  parameters  and  state  variables 

The  event  graph  for  the  CaptureOrKill  component  is  shown  in  Figures  21 
and  22. 
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A 

{g.setCaptured(l) 

Nbc++ 

g.setOab(behaviorEquation5(g.getOab(),  pDCB,  0))} 


B 

{g.setCaptured(2) 

Nrc++ 

g.setOab(behaviorEquation5(g.getOab()/  0,  p)CR))} 

Figure  22.  CaptureOrKill  event  graph  (part  2) 

The  Run  event  initializes  all  state  variables  to  zero. 

The  CaptureOrKillByBlue  event  sees  whether  a  Green  player  will  be 
captured  or  killed  by  a  Blue  player.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter.  It  draws  a  random  uniform  number  between  0  and  1.  If  the  random 
uniform  draw  is  less  than  pCe,  it  schedules  a  GreenCapturedByBlue  event, 
passing  along  the  local  Green  player.  If  the  random  uniform  draw  is  greater  than 
or  equal  to  pCe,  it  schedules  a  GreenKilledByBlue  event,  passing  along  the  local 
Green  player. 

The  GreenCapturedByBlue  event  simulates  a  Green  player  being 
captured  by  a  Blue  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It 
sets  the  captured  status  of  the  local  Green  player  as  if  he  was  captured  by  a  Blue 
player  and  increments  A/ec  by  one.  It  calculates  the  Green  player’s  new  OAB  by 
using  his  current  OAB,  D  =  pDce,  and  I  =  0  in  behavior  Equation  5  (Figure  5).  It 
then  schedules  a  ReplaceGreen  event  and  a  WaitForRelease  event,  passing 
along  the  local  Green  player  to  both. 

The  GreenKilledByBlue  event  simulates  a  Green  player  being  killed  by  a 
Blue  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It  sets  the  killed 
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status  of  the  local  Green  player  as  if  he  was  killed  by  a  Blue  player,  and  it 
increments  Nbk  by  one.  It  then  schedules  a  ReplaceGreen  event,  passing  along 
the  local  Green  player. 

The  CaptureOrKillByRed  event  sees  whether  a  Green  player  will  be 
captured  or  killed  by  a  Red  player.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter.  It  draws  a  random  uniform  number  between  0  and  1.  If  the  random 
uniform  draw  is  less  than  pCR,  it  schedules  a  GreenCapturedByRed  event, 
passing  along  the  local  Green  player.  If  the  random  uniform  draw  is  greater  than 
or  equal  to  pCR,  it  schedules  a  GreenKilledByRed  event,  passing  along  the  local 
Green  player. 

The  GreenCapturedByRed  event  simulates  a  Green  player  being  captured 
by  a  Red  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It  sets  the 
captured  status  of  the  local  Green  player  as  if  he  was  captured  by  a  Red  player 
and  increments  Nrc  by  one.  It  calculates  the  Green  player’s  new  OAB  by  using 
his  current  OAB,  D  =  0,  and  I  =  Picr  in  behavior  Equation  5  (Figure  5).  It  then 
schedules  a  ReplaceGreen  event  and  a  WaitForRelease  event,  passing  along 
the  local  Green  player  to  both. 

The  GreenKilledByRed  event  simulates  a  Green  player  being  killed  by  a 
Red  player.  It  takes  a  GreenPlayer  agent  as  its  local  parameter.  It  sets  the  killed 
status  of  the  local  Green  player  as  if  he  was  killed  by  a  Red  player,  and  it 
increments  NRK  by  one.  It  then  schedules  a  ReplaceGreen  event,  passing  along 
the  local  Green  player. 

The  ReplaceGreen  event  simulates  a  Green  player  being  replaced  by 
another  Green  player  after  being  captured  or  killed.  It  takes  a  GreenPlayer  agent 
as  its  local  parameter. 

The  WaitForRelease  event  simulates  a  Green  player  awaiting  his  release 
after  being  captured.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 
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12.  Release 


The  Release  component  represents  the  releasing  of  Green  players  after 
being  captured.  It  has  one  input  parameter.  It  requires  a  random  distribution 
representing  the  stream  of  times  that  Green  players  are  released  {{Irl}). 

Parameters  for  the  Release  component  are  summarized  in  Table  14. 


Parameter 

Description 

{tRL} 

stream  of  Green  player  release  times 

Table  14.  Release  parameters 


The  event  graph  for  the  Release  component  is  shown  in  Figure  23. 


The  ScheduleRelease  event  simulates  a  Green  player  waiting  for  his 
release  after  being  captured.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 
It  schedules  a  GreenReleased  event  with  a  time  delay  pulled  from  {tRL},  passing 
along  the  local  Green  player. 

The  GreenReleased  event  simulates  a  Green  player  being  released.  It 
takes  a  GreenPlayer  agent  as  its  local  parameter.  It  resets  the  captured  status  of 
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the  local  Green  player  to  show  that  he  is  no  longer  captured.  It  then  schedules  a 
ReplaceReplacement  event,  passing  along  the  local  Green  player. 

The  ReplaceReplacement  event  simulates  a  Green  player  taking  control 
back  from  his  replacement.  It  takes  a  GreenPlayer  agent  as  its  local  parameter. 

The  GreenCanceled  event  simulates  a  Green  player  replacement  that  is 
no  longer  needed  in  the  model.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter.  It  cancels  the  GreenReleased  event  for  the  local  Green  player. 

13.  HandleReplacements 

The  HandleReplacements  component  handles  the  replacing  of  Green 
players  when  they  are  captured,  killed,  or  released.  It  has  13  input  parameters.  It 
requires  one  random  distribution  representing  the  stream  of  times  that  Green 
players  schedule  their  next  arrival  for  another  KLE  ({few})-  The  parameters  pc, 
Pklk ,  Ptk,  and  pRK  are  the  same  parameters  from  the  CreatePlayers  component 
representing  the  probabilities  that  a  Green  player  is  corrupt,  has  key  leader 
critical  knowledge,  has  threat  critical  knowledge,  and  has  resource  critical 
knowledge,  respectively.  The  parameters  Plkb  and  Phkb  represent  the 
probabilities  of  a  Green  replacement  having  a  lower  or  higher  OAB,  respectively, 
than  the  Green  player  that  is  killed  by  a  Blue  player;  the  sum  of  these  two  must 
be  less  than  or  equal  to  1.  The  parameters  pLKR  and  Phkr  represent  the 
probabilities  of  a  Green  replacement  having  a  lower  or  higher  OAB,  respectively, 
than  the  Green  player  that  is  killed  by  a  Red  player;  the  sum  of  these  two  must 
be  less  than  or  equal  to  1.  The  parameters  pLce  and  pHce  represent  the 
probabilities  of  a  Green  replacement  having  a  lower  or  higher  OAB,  respectively, 
than  the  Green  player  that  is  captured  by  a  Blue  player;  the  sum  of  these  two 
must  be  less  than  or  equal  to  1 .  The  parameters  Plcr  and  Phcr  represent  the 
probabilities  of  a  Green  replacement  having  a  lower  or  higher  OAB,  respectively, 
than  the  Green  player  that  is  captured  by  a  Red  player;  the  sum  of  these  two 
must  be  less  than  or  equal  to  1 . 
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The  HandleReplacements  component  has  one  state  variable.  The  variable 
c  represents  a  list  to  hold  captured  Green  players  that  have  a  replacement  in  the 
model. 


Parameters,  parameter  constraints,  and  state  variables  for  the 
HandleReplacements  component  are  summarized  in  Table  15. 


Parameter 

Description 

{^gm} 

stream  of  Green  player  next  meeting  times 

Pc 

probability  of  Green  player  being  corrupt 

Pklk 

probability  of  Green  player  having  key  leader  knowledge 

Ptk 

probability  of  Green  player  having  threat  knowledge 

Prk 

probability  of  Green  player  having  resource  knowledge 

Plkb 

probability  of  replacement  having  lower  OAB  when  Green 

player  killed  by  Blue  player 

Phkb 

probability  of  replacement  having  higher  OAB  when  Green 

player  killed  by  Blue  player 

Plkr 

probability  of  replacement  having  lower  OAB  when  Green 

player  killed  by  Red  player 

Phkr 

probability  of  replacement  having  higher  OAB  when  Green 

player  killed  by  Red  player 

Plcb 

probability  of  replacement  having  lower  OAB  when  Green 

player  captured  by  Blue  player 

Phcb 

probability  of  replacement  having  higher  OAB  when  Green 

player  captured  by  Blue  player 

Plcr 

probability  of  replacement  having  lower  OAB  when  Green 

player  captured  by  Red  player 

Phcr 

probability  of  replacement  having  higher  OAB  when  Green 

player  captured  by  Red  player 

Parameter  Constraint 

Plkb  +  Phkb  ^  1 

Plkr  +  Phkr  ^  1 

Plcb  +  Phcb  -  1 

Plcr  +  Phcr  -  1 

State  Variable 

Description 

c 

list  to  hold  captured  Green  players  that  have  replacement 

Table  15.  HandleReplacements  parameters,  parameter  constraints,  and  state 

variables 
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The  event  graph  for  the  HandleReplacements  component  is  shown  in 
Figure  24. 


{cdearl)} 


{GreenPlayer  r  =  g.getReplacement() 
g.setReplacement(null) 
c.remove(g)} 


{GreenPlayer  r  = 

new  GreenPlayer("GREENREPLACE",  pc,  pKLK,  p^,  pRK) 
if  (g.isKilled()  ==  1)  { 

r.setOab(behaviorEquation5(g.getOab(),  p^g,  pHKB)) 

} 

if  (g.isKilled()  ==  2)  { 

r.setOab(behaviorEquation5(g.getOab()<  pLKR,  pHKR)) 

} 

if  (g.isCaptured()  ==  1)  { 

r.setOab(behaviorEquation5(g.getOab(),  pLCB,  pHCB)) 

} 

if  (g.isCaptured()  ==  2)  { 

r.setOab(behaviorEquation5(g.getOab(),  pLCR,  pHCR)) 

} 

boolean  alreadyReplacement  =  false 
for  (GreenPlayer  glnList :  c)  { 
if  (glnList.getReplacement()  ==  g)  { 
glnList.setReplacement(r) 
alreadyReplacement  =  true 

} 

} 

if  (alreadyReplacement  ==  false  &  (g.isCaptured()  ==  1  |  g.isCapturedQ  ==  2))  { 
g.setReplacement(r) 
c.add(g) 

}} 


Figure  24.  HandleReplacements  event  graph 


The  Run  event  clears  c. 

The  CreateGreenReplacement  event  simulates  a  Green  replacement 
being  added  to  the  model  when  a  Green  player  is  captured  or  killed.  It  takes  a 
GreenPlayer  agent  as  its  local  parameter.  It  creates  a  new  GreenPlayer  agent 
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that  is  the  replacement  for  the  local  Green  player.  If  a  Blue  player  kills  the  local 
Green  player,  it  calculates  the  replacement’s  OAB  by  using  the  Green  player’s 
OAB,  D  =  pLKB ,  and  I  =  Phkb  in  behavior  Equation  5  (Figure  5).  If  the  local  Green 
player  is  killed  by  a  Red  player,  it  calculates  the  replacement’s  OAB  by  using  the 
Green  player’s  OAB,  D  =  Plkr,  and  I  =  Phkr  in  behavior  Equation  5  (Figure  5).  If 
the  local  Green  player  is  captured  by  a  Blue  player,  it  calculates  the 
replacement’s  OAB  by  using  the  Green  player’s  OAB,  D  =  pLCe,  and  I  =  Phcb  in 
behavior  Equation  5  (Figure  5).  If  the  local  Green  player  is  captured  by  a  Red 
player,  it  calculates  the  replacement’s  OAB  by  using  the  Green  player’s  OAB,  D 
=  Plcr,  and  I  =  Phcr  in  behavior  Equation  5  (Figure  5).  Then  it  checks  the  state 
variable,  c,  to  determine  if  the  local  Green  player  that  is  killed  or  captured  is 
already  a  replacement  for  another  captured  Green  player.  If  this  is  the  case,  it 
sets  the  newly  created  replacement  as  the  replacement  for  the  Green  player  in  c. 
Then,  if  the  local  Green  player  is  not  already  a  replacement  and  is  captured,  it 
sets  the  newly  created  replacement  as  his  replacement  and  is  added  to  c.  Lastly, 
it  schedules  a  ScheduleGreenNextMeeting  event  with  a  time  delay  pulled  from 
{tGM},  passing  along  the  created  replacement. 

The  ReplaceReplacement  event  simulates  a  Green  player  being  released 
and  his  replacement  being  no  longer  needed  in  the  model.  It  takes  a 
GreenPlayer  agent  as  its  local  parameter.  It  takes  the  Green  replacement 
assigned  to  the  released  Green  player  and  assigns  this  replacement  to  a  local 
GreenPlayer  agent  variable.  It  resets  the  replacement  of  the  released  Green 
player  to  null,  and  then  it  removes  the  released  Green  player  from  c.  Lastly,  it 
schedules  a  ScheduleGreenNextMeeting  event  with  a  time  delay  pulled  from 
{tGM},  passing  along  the  released  Green  player,  and  it  schedules  a 
CancelReplacement  event,  passing  along  the  replacement. 

The  ScheduleGreenNextMeeting  event  simulates  a  Green  player 
scheduling  his  next  arrival  for  a  KLE.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter. 
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The  CancelReplacement  event  simulates  a  Green  player  replacement  no 
longer  being  needed  in  the  model.  It  takes  a  GreenPlayer  agent  as  its  local 
parameter. 

E.  COMPONENT  LISTENING  STRUCTURE  AND  ADAPTERS  OF  KLE 
MODEL 

The  various  components  of  the  KLE  Model  are  connected  together  as 
shown  in  Figure  25.  The  various  adapters  in  the  KLE  Model  are  listed  in  Table 
16.  When  one  of  the  listed  events  for  a  given  component  is  executed,  the 
respective  listening  component  schedules  the  appropriate  event.  For  more 
information  on  connecting  event  graphs  using  listeners  and  adapters,  see  Buss 
(2011). 
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EXECUTED  COMPONENT/EVENT 

LISTENING  COMPONENT/EVENT 

Component 

Event 

Component 

Event 

Create 

BluePlayer 

Handle 

BluePlayer 

Players 

Arrival 

EngagementType 

Arrival 

Create 

GreenPlayer 

Handle 

GreenPlayer 

Players 

Arrival 

EngagementType 

Arrival 

MicroKeyLeader 

ScheduleBlue 

Handle 

BluePlayer 

Engagement 

NextMeeting 

EngagementType 

Arrival 

KeyLeader 

ScheduleBlue 

Handle 

BluePlayer 

Engagement 

NextMeeting 

EngagementType 

Arrival 

Campaign 

ScheduleGreen 

Handle 

GreenPlayer 

NextMeeting 

EngagementType 

Arrival 

Handle 

ScheduleGreen 

Handle 

GreenPlayer 

Replacements 

NextMeeting 

EngagementType 

Arrival 

Handle 

Cancel 

Handle 

Green 

Replacements 

Replacement 

EngagementType 

Canceled 

Handle 

BlueReady 

MicroKeyLeader 

Start 

EngagementType 

ForMicroKLE 

Engagement 

MicroKLE 

Handle 

SendPlayers 

KeyLeader 

Start 

EngagementType 

ToKLE 

Engagement 

KLE 

Handle 

Cancel 

KeyLeader 

Green 

Replacements 

Replacement 

Engagement 

Canceled 

KeyLeader 

Handle 

Handle 

StartMessage 

Engagement 

Requests 

MessageRequest 

Request 

Handle 

EndMessage 

HandleKeyLeader 

StartKeyLeader 

MessageRequest 

Request 

KnowledgeRequest 

KnowledgeRequest 

HandleKeyLeader 

End  KeyLeader 

HandleThreat 

StartThreat 

KnowledgeRequest 

KnowledgeRequest 

KnowledgeRequest 

KnowledgeRequest 

HandleThreat 

EndThreat 

HandleResource 

StartResource 

KnowledgeRequest 

KnowledgeRequest 

KnowledgeRequest 

KnowledgeRequest 

HandleResource 

EndResource 

UpdateOAB 

CheckGreen 

KnowledgeRequest 

KnowledgeRequest 

Status 

Update 

OAB 

Campaign 

Campaign 

Check 

OAB 

Handle 

Replacements 

Cancel 

Replacement 

Campaign 

Green 

Canceled 

Update 

OAB 

CaptureOr 

KillByBlue 

CaptureOrKill 

CaptureOr 

KillByBlue 

Update 

OAB 

CaptureOr 

KillByRed 

CaptureOrKill 

CaptureOr 

KillByRed 

Campaign 

CaptureOr 

KillByBlue 

CaptureOrKill 

CaptureOr 

KillByBlue 

Campaign 

CaptureOr 

KillByRed 

CaptureOrKill 

CaptureOr 

KillByRed 

Capture 

WaitFor 

Release 

Schedule 

OrKill 

Release 

Release 

Handle 

Cancel 

Release 

Green 

Replacements 

Replacement 

Canceled 

Capture 

Replace 

Handle 

CreateGreen 

OrKill 

Green 

Replacements 

Replacement 

Release 

Replace 

Handle 

Replace 

Replacement 

Replacements 

Replacement 

Table  16.  KLE  Model  adapters 
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III.  DESIGN  OF  EXPERIMENTS 


Chapter  III  begins  with  a  brief  discussion  on  the  use  of  random  number 
generators  in  the  Key  Leader  Engagement  (KLE)  Model.  Then  we  discuss  what 
model  input  parameters  were  not  varied  and  those  that  were,  including  their  low 
and  high  values.  We  talk  briefly  about  the  nearly  orthogonal  and  balanced  mixed 
design  of  experiments  that  was  utilized  for  further  analysis  of  the  model.  The 
chapter  ends  with  a  small  discussion  on  the  scenario  replication  and  three 
scenarios  (one-week,  nine-weeks,  and  one-year)  that  were  executed. 

A.  RANDOM  NUMBER  GENERATION 

Two  random  number  streams  are  used  to  run  the  KLE  Model.  One 
generator  creates  random  seeds  for  each  design  point  run,  and  the  other 
generator  utilizes  the  seed  to  generate  random  numbers  that  are  needed  when 
running  the  model  components.  The  two  random  number  streams  used  when 
running  the  KLE  Model  both  use  the  Mersenne  Twister  MT  19937  pseudorandom 
number  generator  (Wikipedia  2012). 

B.  HANDLING  OF  INPUT  PARAMETERS 

1 .  Static  Parameters 

The  input  parameters  not  varied  in  the  design  of  experiments  are  those 
associated  with  numbers  of  players  and  all  streams  of  time.  The  constant  values 
assigned  to  these  static  parameters  are  best-guess  estimates  derived  from 
military  and  civilian  analysts  at  TRAC-Monterey  that  best  coincide  with  what  can 
be  expected  during  a  tactical  wargame  (TWG)  using  an  Afghanistan  scenario. 
The  time  streams  are  all  triangle  distributed  (minimum,  maximum,  mode). 

Table  17  lists  the  parameters  that  are  not  varied,  the  component(s)  they 
are  found  in,  and  their  associated  values. 
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Parameter 

Component(s) 

Value 

NBp 

CreatePlayers 

4 

Ngp 

CreatePlayers 

17 

{^nm) 

HandleEngagementType 

Triangle(0.25,l,0.5) 

Unk) 

HandleEngagementType 

Triangle(l, 168,48) 

{{rg} 

HandleEngagementType 

Triangle(l, 168,48) 

{^bm} 

HandleEngagementType 

MicroKeyLeaderEngagement 

KeyLeaderEngagement 

Triangle(24,72,48) 

Um} 

MicroKeyLeaderEngagement 

Triangle(0.1,0.5,0.2) 

{tj 

KeyLeaderEngagement 

Triangle(l,6,4) 

Unc} 

Campaign 

Triangle(l, 168,24) 

{tc} 

Campaign 

Triangle(0. 5,48,3) 

{^bm} 

Campaign 

HandleReplacements 

Triangle(24, 336,96) 

{^rl} 

Release 

Triangle(24, 8760,2160) 

Table  17.  Static  model  parameters  and  their  values 


2.  Dynamic  Parameters  and  NOB  Mixed  Design 

The  input  parameters  varied  in  the  design  of  experiments  are  those 
associated  with  probabilities  and  probability  factors.  Probabilities  not  associated 
with  OAB  changes  or  assignments  are  varied  from  0  to  1.  Probabilities 
associated  with  OAB  changes  and  assignments  are  varied  from  0  to  0.5  due  to 
the  decrease/increase  or  lower/higher  pairings  used  in  behavior  Equation  5 
(Figure  5).  Probability  factors  are  varied  from  0  to  0.2.  The  baseline  probabilities, 
Pbckb  and  Pbckr,  are  varied  from  0  to  0.0208  due  to  the  parameter  restriction  that 
these  two  individually  multiplied  by  the  maximum  campaign  time  (48)  must  be 
less  than  or  equal  to  1 . 

Tables  18  and  19  list  the  parameters  that  are  varied,  the  component(s) 
they  are  found  in,  and  their  associated  low  and  high  values. 
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Parameter 

Component(s) 

Low  Value 

High  Value 

Pi 

CreatePlayers 

KeyLeaderEngagement 

0 

1 

Pc 

CreatePlayers 

HandleReplacements 

0 

1 

Pklk 

CreatePlayers 

HandleKeyLeaderKnowledgeRequest 

HandleReplacements 

0 

1 

Ptk 

CreatePlayers 

HandleThreatKnowledgeRequest 

HandleReplacements 

0 

1 

Prk 

CreatePlayers 

HandleResourceKnowledgeRequest 

HandleReplacements 

0 

1 

PfRG 

HandleEngagementType 

0 

0.2 

PfNS 

HandleEngagementType 

0 

0.2 

ptcK 

MicroKeyLeaderEngagement 

0 

0.2 

pfBT 

HandleMessageRequest 

HandleKeyLeaderKnowledgeRequest 

HandleThreatKnowledgeRequest 

HandleResourceKnowledgeRequest 

0 

0.2 

Pf  HR 

HandleMessageRequest 

HandleKeyLeaderKnowledgeRequest 

HandleThreatKnowledgeRequest 

HandleResourceKnowledgeRequest 

0 

0.2 

pf  HRI 

HandleMessageRequest 

HandleKeyLeaderKnowledgeRequest 

HandleThreatKnowledgeRequest 

HandleResourceKnowledgeRequest 

0 

0.2 

P^HRT 

HandleMessageRequest 

HandleKeyLeaderKnowledgeRequest 

HandleThreatKnowledgeRequest 

HandleResourceKnowledgeRequest 

0 

0.2 

Table  18.  Dynamic  model  parameters  and  their  values  (part  1 ) 
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Parameter 

Component(s) 

Low  Value 

High  Value 

Pdo 

UpdateOAB 

0 

0.5 

Pio 

UpdateOAB 

0 

0.5 

Pdi 

UpdateOAB 

0 

0.5 

Pii 

UpdateOAB 

0 

0.5 

Pdt 

UpdateOAB 

0 

0.5 

Pit 

UpdateOAB 

0 

0.5 

Pbckb 

UpdateOAB 

Campaign 

0 

0.0208 

Pbckr 

UpdateOAB 

Campaign 

0 

0.0208 

PCB 

CaptureOrKill 

0 

1 

PcR 

CaptureOrKill 

0 

1 

Pdcb 

CaptureOrKill 

0 

0.5 

PlCR 

CaptureOrKill 

0 

0.5 

Plkb 

HandleReplacements 

0 

0.5 

Phkb 

HandleReplacements 

0 

0.5 

Plkr 

HandleReplacements 

0 

0.5 

Phkr 

HandleReplacements 

0 

0.5 

Plcb 

HandleReplacements 

0 

0.5 

Phcb 

HandleReplacements 

0 

0.5 

Plcr 

HandleReplacements 

0 

0.5 

Phcr 

HandleReplacements 

0 

0.5 

Table  19.  Dynamic  model  parameters  and  their  values  (part  2) 

The  design  is  constructed  using  the  512-design  point  nearly  orthogonal 
and  balanced  (NOB)  mixed  design  spreadsheet  of  Vieira  (2012).  The  result  is  a 
nearly  orthogonal  Latin  hypercube  (NOLH)  since  all  parameters  in  this  design  are 
continuous-valued.  For  more  details  about  the  properties  or  application  of  NOLH 
designs,  see  Kleijnen  et  al.  (2005)  or  Sanchez  et  al.  (2012).  For  more  details 
about  NOB  designs,  which  can  also  handle  discrete-valued  factors  with  limited 
numbers  of  levels,  see  Vieira  et  al.  (201 1 ,  2012). 
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C.  SCENARIO  REPLICATION 

In  order  to  assist  with  the  code  verification  efforts  of  the  KLE  Model,  three 
different  scenarios  are  used.  Within  the  model,  one  unit  of  simulated  time 
represents  one  hour  of  real  time.  The  first  scenario  looks  at  short-term  effects 
within  the  model  and  warm-up  period  issues;  the  model  is  run  for  168  time  units 
(hours)  to  represent  the  span  of  a  week.  The  second  looks  at  mid-range  effects; 
the  model  is  run  for  1,512  time  units  to  represent  the  span  of  nine  weeks,  the 
typical  run  time  for  a  TWG.  The  third  looks  at  long-term  effects  and  convergence 
issues;  the  model  is  run  for  8,760  time  units  to  represent  the  span  of  a  year. 
Additionally,  each  design  point  for  each  scenario  is  replicated  200  times  to  collect 
summary  statistics  for  analysis,  and  to  allow  for  the  possibility  of  examining  the 
variances  as  well  as  the  means  of  the  output  responses  of  interest. 
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IV.  KLE  MODEL  ANALYSIS 


Chapter  IV  begins  with  a  short  description  of  the  model  output  data.  The 
analysis  begins  with  a  look  at  the  significant  input  parameters  used  to  build 
regression  metamodels  and  partition  tree  models  to  help  verify  the  KLE  Model 
execution.  We  then  look  at  the  output  summary  statistics  to  gain  insights  into  the 
ranges  and  the  variability  of  the  output  responses.  Finally,  some  discussion  on 
the  number  of  micro-KLEs  response  is  presented  given  the  apparently 
anomalous  behavior  of  this  output  variable. 

A.  OUTPUT  DATA 

The  outputs  analyzed  in  the  KLE  Model  are  associated  with  all  the 
countable  state  variables  within  the  model  components;  these  are  of  interest  as 
they  correlate  to  the  outputs  analyzed  during  a  TRAC  tactical  wargame  (TWG). 
For  each  design  point,  we  collect  the  final  values  of  the  state  variables  for  all  200 
replications.  We  then  output  the  mean,  standard  deviation,  minimum  value,  and 
maximum  value  for  the  200  replications. 

B.  SIGNIFICANT  INPUT  PARAMETERS  AND  MODEL  VERIFICATION 

In  order  to  explore  the  significant  input  factors  for  each  of  the  output 
responses,  and  subsequently  help  verify  the  expected  functionality  of  the  KLE 
Model,  we  first  derive  second-order  regression  metamodels  that  best  fit  each 
output  response.  A  stepwise  regression  control  with  a  minimum  Bayesian 
information  criterion  stopping  rule  is  used  to  find  the  input  parameters  that  are 
significant  in  predicting  the  responses.  These  parameters  (after  removing  less 
significant  terms)  are  then  used  to  fit  the  regression  metamodel  using  standard 
least  squares.  From  the  sorted  parameter  estimates,  we  can  see  which  input 
parameters  are  the  most  significant.  Second,  we  create  partition  tree  models  with 
up  to  20  splits  if  needed  to  identify  the  most  significant  input  parameters  for  each 
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response;  this  helps  verify  the  significant  parameters  derived  in  the  regression 
metamodels.  The  statistical  software  JMP®  Pro  9.0  was  used  to  create  these 
regression  metamodels  and  partition  tree  models. 

To  get  an  idea  of  the  regression  metamodels  and  partition  tree  models 
created,  we  use  the  number  of  KLEs  output  response  as  an  example.  Starting 
with  the  metamodels,  Figures  26,  27,  and  28  show  the  second-order  regression 
metamodels  for  the  number  of  KLEs  in  the  one-week,  nine-week,  and  one-year 
scenarios,  respectively.  All  three  metamodels  show  an  F-statistic  p-value  of  less 
than  0.0001,  indicating  statistical  significance  in  all  cases;  all  three  have  relatively 
high  R-squared  values  (greater  than  0.9);  and  all  three  metamodels  have  terms 
that  are  statistically  significant  (t-statistic  p-values  less  than  0.01).  We  remark 
that  with  such  a  large  data  set,  statistical  significance  is  necessary  but  not 
sufficient  for  including  terms  in  the  metamodels.  In  some  cases,  we  have 
eliminated  terms  with  p-values  less  than  0.01  in  the  interests  of  parsimony,  when 
their  inclusion  leads  to  very  little  improvement  in  a  metamodel’s  R-squared  value. 
Figure  27  illustrates  this  phenomenon;  if  we  simplified  the  metamodel  even 
further  by  eliminating  the  four  interaction  terms  with  p-values  between  0.0003 
and  0.0020,  the  R-squared  value  would  drop  only  slightly  (from  0.9898  to 
0.9886).  The  simplified  metamodel  is  preferable.  Similar  simplifications  could  be 
made  for  the  one-year  metamodel. 

From  these  regression  metamodels,  we  see  that  the  renege  probability 
factor  (p/rg)  and  the  no-show  probability  factor  (pA/s)  are  the  two  most  significant 
parameters  for  the  one-week  and  nine-week  scenarios  and  within  the  top  three 
for  the  one-year  scenario.  These  two  parameters  are  the  primary  factors  of 
whether  a  Blue  player  engages  a  Green  player,  and  as  model  runtime  increases, 
these  factors  remain  significant,  which  is  what  we  were  looking  for  in  the  KLE 
Model  execution.  The  figures  also  exhibit  the  increasing  complexity  of  the 
metamodels  as  runtime  increases  due  to  the  greater  influence  of  cross¬ 
component  effects,  which  is  expected. 
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Actual  by  Predicted  Plot 


Summary  of  Fit 

RSquare  0.984757 

RSquare  Adj  0.984667 

Root  Mean  Square  Error  0.086814 

Mean  of  Response  3.017539 

Observations  (or  Sum  Wgts)  512 

Analysis  of  Variance 


Source 

DF 

Sum  of 
Squares 

Mean  Square 

F  Ratio 

Model 

3 

247.33762 

82.4459 

10939.29 

Error 

508 

3.82863 

0.0075 

Prob  >  F 

C.  Total 

511 

251.16625 

<0001* 

Sorted  Parameter  Estimates 

Term  Estimate  Std  Error  t  Ratio 

pf_RG  -8.533547  0.066527  -128.3 

pf_NS  -8.435853  0.0664  -127.0 

(pf_RG-0.1  )*(pf_NS-0.1)  40.781917  1.162246  35.09 


Prob>itl 

<.0001* 

<0001* 

<0001* 


Figure  26.  Number  of  KLEs  regression  metamodel  (1  week) 
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Actual  by  Predicted  Plot 


Summary  of  Fit 


Summary  of  Fit 

RSquare  0.989796 

RSquare  Adj  0.989593 

Root  Mean  Square  Error  0.72012 

Mean  of  Response  26.67324 

Observations  (or  Sum  Wgts)  512 


Analysis  of  Variance 


Sum  of 


Source 

DF 

Squares 

Mean  Square 

F  Ratio 

Model 

10 

25202.059 

2520.21 

4859.890 

Error 

501 

259.805 

0.52 

Prob  >  F 

C.  Total 

511 

25461 .864 

<.0001* 

Sorted  Parameter  Estimates 


Term 

Estimate 

Std  Error 

t  Ratio 

Prob>itl 

pf  NS 

-84.88342 

0.550977 

-154.1 

<.0001* 

pf  RG 

-85.14389 

0.552799 

-154.0 

<.0001* 

(pf_RG-0.1  )*(pf_NS-0.1) 

401.85299 

9.667813 

41.57 

<.0001* 

p_KLK 

-2.383182 

0.110567 

-21.55 

if 

<.0001* 

pf_HR 

-9.853123 

0.552565 

-17.83 

it 

<.0001* 

(p_KLK-0.5)*(pf_HR-0.1) 

-26.35962 

1 .904628 

-13.84 

it 

<.0001* 

(p_KLK-0.5)*(pf_RG-0.1) 

6.8493926 

1 .867203 

3.67 

0.0003* 

(p_KLK-0.5)*(pf_NS-0.1 ) 

6.9780912 

1 .936586 

3.60 

0.0003* 

(pf_NS-0. 1  )*(pf_HR-0. 1 ) 

30.764916 

9.286546 

3.31 

0.0010* 

(pf_RG-0. 1  )'(pf_HR-0. 1 ) 

29.482919 

9.469376 

3.11 

0.0020* 

Figure  27.  Number  of  KLEs  regression  metamodel  (9  weeks) 
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Actual  by  Predicted  Plot 


Summary  of  Fit 

RSquare  0.907715 

RSquare  Adj  0.904346 

Root  Mean  Square  Error  13.52019 

Mean  of  Response  105.2959 

Observations  (or  Sum  Wgts)  512 

Analysis  of  Variance 

Sum  of 


Source 

DF 

Squares 

Mean  Square 

F  Ratio 

Model 

18 

886404.52 

49244.7 

269.3975 

Error 

493 

90118.26 

182.8 

Prob  >  F 

C.  Total 

511 

976522.78 

<0001* 

Sorted  Parameter  Estimates 


Term 

Estimate 

Std  Error 

t  Ratio 

p_KLK 

-86.86023 

2.091336 

-41.53 

pf_NS 

-293.6074 

10.43467 

-28.14 

pf_HR 

-292.9832 

10.41999 

-28.12 

pf_RG 

-288.615 

10.38332 

-27.80 

(p_KLK-0.5)*(pf_NS-0.1 ) 

446.60665 

36.70415 

12.17 

(p_KLK-0.5)*(pf_RG-0.1) 

369.44452 

35.37955 

10.44 

(p_KLK-0.5)*(pf_HR-0. 1 ) 

-353.6441 

36.07581 

-9.80 

(pf_NS-0. 1  )*(pf_HR-0. 1 ) 

1474.9089 

176.3731 

8.36 

(pf  RG-0.1)*(pf  HR-0.1) 

1338.5144 

178.5741 

7.50 

P_C 

-12.1191 

2.083207 

-5.82 

P_l 

-9.853334 

2.091881 

-4.71 

pf_BT 

-46.77026 

10.38876 

-4.50 

pf_HRT 

-44.15599 

10.45169 

-4.22 

(p_C-0 . 5)  *  (pf  _H  R-0 . 1 ) 

1 54.45205 

37.13474 

4.16 

(pf_HR-0.1)*(pf_HRI-0.1) 

710.98815 

185.4616 

3.83 

pfHRI 

-36.66194 

10.4566 

-3.51 

(p_KLK-0.5)*(pf_HRT-0.1) 

-112.5208 

36.64736 

-3.07 

(pf_RG-0. 1  )*(pf_NS-0. 1 ) 

523.22212 

182.6806 

2.86 

Prob>ttl 

<.0001* 
<.0001* 
<.0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
<0001* 
0.0001  * 
0.0005* 
0.0023* 
0.0044* 


Figure  28.  Number  of  KLEs  regression  metamodel  (1  year) 
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Figures  29,  30,  and  31  show  the  partition  tree  models  for  the  number  of 
KLEs  in  the  one-week,  nine-week,  and  one-year  scenarios,  respectively.  These 
trees  back-up  what  was  discovered  in  the  regression  metamodels,  especially  the 
initial  split  using  the  probability  of  having  key  leader  critical  knowledge  (pklk)  in 
the  one-year  scenario  (Figure  31),  which  corresponds  to  the  parameter’s 
significance  in  the  one-year  regression  metamodel  (Figure  28).  For  simplicity, 
only  three  or  four  levels  within  the  partition  trees  are  displayed.  The  resulting  R- 
squared  values  are  lower  than  they  were  for  the  corresponding  regression 
metamodels.  Even  so,  looking  at  the  output  in  both  ways  is  useful,  since 
responses  with  discontinuities  in  the  results  may  fit  much  better  with  partition  tree 
models  than  with  regression  metamodels.  Partition  trees  are  also  sometimes 
easier  graphs  for  communicating  with  decision  makers  (Sanchez  et  al.  2012). 


Figure  29.  Number  of  KLEs  partition  tree  model  (1  week) 
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Figure  30.  Number  of  KLEs  partition  tree  model  (9  weeks) 


Figure  31 .  Number  of  KLEs  partition  tree  model  (1  year) 

Having  discussed  the  techniques  used  to  derive  the  second-order 
regression  metamodels  and  partition  tree  models,  Tables  20,  21,  and  22  show 
which  input  parameters  are  the  top  three  most  significant  when  building  the 
metamodels  (denoted  by  #)  and  tree  models  (denoted  by  &)  for  the  output 
responses  for  the  one-week  scenario,  nine-week  scenario,  and  one-year 


87 


scenario,  respectively.  Two  count  columns  show  the  total  number  of  times  an 
input  parameter  is  one  of  the  top  three  most  significant  in  the  regression 
metamodels  and  likewise  for  the  partition  tree  models. 


Input 

Param 

Regr 

Meta- 

Models 

Count 

Part 

Trees 

Count 

Nmklc 

Ntkg 

Nrle 

Nhrm 

NHrk 

Nhrt 

Nhrr 

Nre 

nac 

Nbc 

Nbk 

Nrc 

Nrk 

Pi 

0 

0 

Pc 

0 

0 

Pklk 

6 

5 

tf  & 

#& 

tf  & 

#& 

# 

tf  & 

Ptk 

1 

1 

#& 

Prk 

1 

1 

tf  & 

Pf|*G 

6 

4 

tf  & 

tf  & 

tf 

tf  & 

#& 

# 

Pf  NS 

4 

6 

tf  & 

tf  & 

#& 

& 

tf  & 

& 

PfCK 

1 

1 

#& 

PffiT 

0 

0 

pfriR 

6 

6 

#& 

#& 

tf  & 

tf  & 

tf  & 

tf  & 

pfHRI 

0 

0 

pfHRT 

0 

0 

Poo 

0 

0 

PlO 

0 

0 

Pdi 

0 

0 

Pll 

0 

0 

Pdt 

0 

0 

Pn 

0 

0 

Pbckb 

2 

2 

tf  & 

tf  & 

Pbckr 

2 

2 

tf  & 

tf  & 

PCS 

2 

2 

tf  & 

tf  & 

Pcr 

2 

2 

tf  & 

#& 

PocB 

0 

0 

Pkr 

0 

1 

& 

Plkb 

0 

0 

Phkb 

0 

0 

Plkr 

0 

0 

Phkr 

0 

0 

Plcb 

0 

0 

Phcb 

0 

0 

Plcr 

0 

0 

Phcr 

0 

0 

tf  =  parameter  included  in  regression  metamodel  that  is  one  of  top  three  most  significant 
&  =  parameter  included  in  partition  tree  model  that  is  one  of  top  three  most  significant 


Table  20.  Top  three  significant  input  parameters  (1  week). 
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Input 

Param 

Regr 

Meta- 

Models 

Count 

Part 

Trees 

Count 

Nmkl£ 

Ntkg 

Nkle 

Nhrm 

Nhrk 

Nhrt 

Nhrr 

Npc 

Nac 

Nbc 

Nbk 

Nrc 

Nrk 

Pi 

0 

0 

Pc 

0 

0 

Pklk 

9 

9 

#& 

#& 

# 

& 

#& 

#& 

#& 

#& 

#& 

#& 

Ptk 

1 

1 

#& 

Prk 

1 

1 

#& 

pfRG 

7 

6 

& 

#& 

#& 

# 

#& 

tt 

#& 

& 

# 

PfNS 

5 

6 

#& 

#& 

#& 

& 

#& 

# 

& 

PfCK 

0 

1 

& 

PfBT 

0 

0 

pf  HR 

8 

6 

# 

ft 

#& 

#& 

#& 

#& 

#& 

#& 

pfHRI 

0 

0 

pfHRT 

0 

0 

Poo 

0 

0 

Pm 

0 

0 

Pdi 

0 

0 

Pn 

0 

0 

Pot 

0 

0 

Pn 

0 

0 

PbCKB 

2 

2 

#& 

#& 

Pbckr 

2 

2 

#& 

#& 

PCB 

2 

2 

#& 

#& 

PCR 

2 

2 

#& 

»  & 

Pdcb 

0 

0 

PlCR 

0 

0 

Plkb 

0 

0 

Phkb 

0 

0 

Plkr 

0 

0 

Phkr 

0 

0 

Plcb 

0 

0 

Phcs 

0 

0 

Plcr 

0 

0 

Phcr 

0 

0 

#  =  parameter  included  in  regression  metamodel  that  is  one  of  top  three  most  significant 
&  =  parameter  included  in  partition  tree  model  that  is  one  of  top  three  most  significant 


Table  21 .  Top  three  significant  input  parameters  (9  weeks) 
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Input 

Param 

Regr 

Meta 

Models 

Count 

Part 

Trees 

Count 

hi  MKLE 

Ntkg 

Nkle 

Nhrm 

Nhrk 

Nhrt 

Nmrr 

Nrc 

Nac 

Nbc 

Nbk 

Nrc 

Nrk 

P. 

0 

0 

Pc 

0 

0 

Pklk 

10 

11 

#& 

#& 

tt  & 

#& 

#& 

#& 

#& 

#& 

& 

tt& 

#& 

Ptk 

1 

1 

#& 

Prk 

1 

1 

#& 

PfpG 

7 

3 

#& 

# 

#& 

# 

#& 

tt 

# 

pfNs 

3 

4 

# 

#& 

& 

tt  & 

& 

PfCK 

1 

1 

#& 

P^BT 

0 

0 

PfHR 

6 

7 

& 

tt& 

& 

#& 

#& 

#& 

# 

#& 

pfHRI 

0 

0 

pfflRT 

0 

0 

Pdo 

1 

2 

#  & 

& 

P» 

0 

1 

& 

Poi 

0 

0 

Pll 

0 

0 

Pot 

0 

0 

Pn 

1 

0 

Pbckb 

2 

2 

#& 

#& 

Pbckr 

2 

2 

tt& 

#& 

PcB 

2 

2 

#& 

tt  & 

PCR 

2 

2 

tt  & 

#& 

Pdcb 

0 

0 

PlCR 

0 

0 

Plkb 

0 

0 

Pmkb 

0 

0 

Plkr 

0 

0 

Phkr 

0 

0 

Plcb 

0 

0 

Phcb 

0 

0 

Plcr 

0 

0 

Phcr 

0 

0 

#  =  parameter  included  in  regression  metamodel  that  is  one  of  top  three  most  significant 
&  =  parameter  included  in  partition  tree  model  that  is  one  of  top  three  most  significant 


Table  22.  Top  three  significant  input  parameters  (1  year) 
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In  all  three  scenarios,  we  see  that  Pklk,  pfRG,  pfNs,  and  pfHR  are  the  input 
parameters  that  are  considered  most  significant  the  most  times  (counts 
highlighted  in  green)  for  both  regression  metamodels  and  partition  tree  models. 
The  renege  probability  factor  (pfRG)  and  the  no-show  probability  factor  (pf/vs) 
make  intuitive  sense  as  these  dictate  whether  a  Green  player  ultimately  shows 
up  and  partakes  in  a  KLE,  and  KLEs  are  the  driving  force  for  most  of  the  model 
outputs.  The  honoring  requests  probability  factor  (p/hr)  also  makes  intuitive 
sense  as  many  actions  that  occur  after  KLEs  depend  on  whether  the  Green 
player  honored  the  various  Blue  player  requests. 

The  probability  of  having  key  leader  critical  knowledge  ( Pklk )  seems 
peculiar  as  to  why  it  is  so  important  in  predicting  the  various  outputs;  for  instance, 
what  does  the  number  of  pro-coalition  force  campaigns  have  to  do  with  whether 
or  not  a  Green  player  has  critical  knowledge  on  other  key  leaders?  If  a  Green 
player  has  key  leader  critical  knowledge,  he  can  be  incentivized  or  threatened  to 
give  this  knowledge  to  a  Blue  player  during  a  KLE.  If  he  is  incentivized  or 
threatened,  this  can  more  significantly  affect  whether  or  not  his  OAB  is  updated 
following  a  KLE.  This  in  turn  impacts  whether  or  not  he  will  conduct  a  pro¬ 
coalition  force  campaign.  Likewise,  if  the  Green  player  does  not  have  key  leader 
critical  knowledge,  he  is  never  incentivized  or  threatened,  and  so  his  OAB  is  less 
likely  to  change  and  the  impact  on  conducting  a  pro-coalition  force  campaign  is 
reduced.  This  effect-tracing  through  the  various  components  applies  to  all  the 
output  responses. 

Using  Tables  21,  22,  and  23,  we  can  verify  the  functionality  of  the  KLE 
Model  and  confirm  that  it  worked  properly  over  a  large  range  of  inputs.  The 
number  of  micro-KLEs  output  is  anomalous  and  is  discussed  in  more  detail  in 
section  D.  The  number  of  times  knowledge  is  gained  during  micro-KLEs  is 
expected  to  be  linked  to  the  chance  of  knowledge  probability  factor  (p/cx),  and 
the  metamodels  and  tree  models  support  this  fact.  The  number  of  KLEs  is 
discussed  in  the  example  at  the  beginning  of  this  section,  and  those  analytical 
models  support  the  expected  behavior  of  the  KLE  Model. 
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For  the  honoring  request  outputs  (pass  message,  provide  key  leader 
critical  knowledge,  provide  threat  critical  knowledge,  and  provide  resource  critical 
knowledge),  we  expect  pfRG  and  pfNS  to  be  important  (we  cannot  honor  requests 
during  KLEs  if  we  do  not  attend  KLEs),  as  well  as  pfHR.  Additionally,  for  the  three 
critical  knowledge-related  outputs,  we  expect  the  probabilities  of  having  said 
knowledge  (pklk,  Ptk,  and  pRK)  to  help  predict  the  respective  responses,  and  they 
show  up  in  the  analytical  models  with  high  significance. 

For  the  pro-  and  anti-coalition  force  campaign  outputs,  we  expect  pfRG  and 
pf/vs  to  be  important  (we  cannot  campaign  following  KLEs  if  we  do  not  attend 
KLEs),  as  well  as  pfRR  since  honoring  or  not  honoring  requests  leads  to  potential 
incentives  and  threats  that  can  impact  the  OAB  updating  following  a  KLE;  the 
OAB  directly  impacts  what  type  of  campaign  will  occur.  Once  again,  these  factors 
show  up  in  the  analytical  models  with  high  significance. 

The  last  set  of  outputs  (the  capture  and  kill  outputs)  verify  the  capturing 
and  killing  functionality  by  using  the  baseline  probabilities  of  capture  or  kill  by 
Blue  players  ( Pbckb )  or  by  Red  players  ( Pbckr )  and  the  probabilities  of  capturing 
vice  killing  by  Blue  players  (pCB)  or  by  Red  players  ( pCR ).  We  expect  the 
respective  Blue  player  probabilities  to  be  significant  when  predicting  captures 
and  kills  by  Blue  players,  and  likewise  for  the  Red  player  probabilities.  The 
metamodels  and  tree  models  support  this  fact  in  all  cases. 

C.  SUMMARY  STATISTICS  ANALYSIS 

Using  JMP®,  the  distributions  of  the  means,  standard  deviations, 
minimums,  and  maximums  are  attained  for  each  output  response  per  scenario. 
The  goal  is  to  gain  insights  into  what  the  KLE  Model  can  provide  regarding 
issues  such  as  variability  or  outliers.  These  snapshots  include  histograms,  outlier 
boxplots,  quantile  data,  and  moment  data.  The  summary  statistics  can  be  used 
(along  with  the  histograms)  to  qualitatively  assess  whether  the  output  is 
reasonable  or  not. 
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Once  again  we  use  the  number  of  KLEs  response  as  our  example,  and 
the  distributions  can  be  seen  in  Figures  32,  33,  and  34  for  the  one-week,  nine- 
week,  and  one-year  scenarios,  respectively.  We  see  that  the  various  data  are 
well-distributed  but  with  some  skewness,  especially  in  the  mean  and  minimum 
histograms  for  all  three  runtimes.  Note  that  there  is  no  reason  to  expect  that  the 
distribution  of  the  design  point  means  should  be  symmetric,  since  the  design 
point  results  arise  from  different  combinations  of  inputs.  In  this  example,  there 
are  no  significant  outliers.  Using  the  number  of  KLEs  mean  statistics,  and  just 
using  plus  or  minus  one  standard  deviation  from  its  mean,  we  expect  our  model 
to  produce  2  to  4  KLEs  in  one  week,  20  to  34  KLEs  over  nine  weeks,  and  62  to 
149  KLEs  over  one  year.  This  appears  to  scale  nicely  as  runtime  increases  and 
so  this  range  of  values  seems  reasonable.  Even  when  we  look  at  the  minimum 
and  maximum  numbers  of  KLEs  experienced  in  all  three  scenarios,  getting  these 
minimums  and  maximums  as  results  is  reasonable  also. 
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N  KLE.mean 


Quantiles 


100.0% 

maximum 

4.82 

99.5% 

4.73718 

97.5% 

4.52438 

90.0% 

4.002 

75.0% 

quartile 

3.52875 

50.0% 

median 

2.955 

25.0% 

quartile 

2.455 

10.0% 

2.17 

2.5% 

1.87913 

0.5% 

1.76065 

0.0% 

minimum 

1  63 

Moments 

Mean 

3.0175391 

Std  Dev 

0.7010842 

Std  Err  Mean 

0.0309838 

Upper  95%  Mean 

3.0784104 

Lower  95%  Mean 

2.9566677 

N 

512 

N  KLE.sd 


Quantiles 


100.0% 

maximum 

1 .45726 

99.5% 

1.40151 

97.5% 

1 .33325 

90.0% 

1 .28905 

75.0% 

quartile 

1.24318 

50.0% 

median 

1.19859 

25.0% 

quartile 

1.14951 

10.0% 

1.11164 

2.5% 

1 .04985 

0.5% 

0.99824 

0.0% 

minimum 

0.98928 

Moments 

Mean 

1.1971577 

Std  Dev 

0.0708696 

Std  Err  Mean 

0.003132 

Upper  95%  Mean 

1.2033109 

Lower  95%  Mean 

1.1910045 

N 

512 

N  KLE.min 


Quantiles 

100.0% 

maximum  2 

99.5% 

2 

97.5% 

2 

90.0% 

1 

75.0% 

quartile  0 

50.0% 

median  0 

25.0% 

quartile  0 

10.0% 

0 

2.5% 

0 

0.5% 

0 

0.0% 

minimum  0 

Moments 

Mean 

0.28125 

Std  Dev 

0.5336064 

Std  Err  Mean  0.0235823 

Upper  95%  Mean  0.3275802 

Lower  95%  Mean  0.23491 98 

N 

512 

N  KLE.max 


Quantiles 

100.0%  maximum 

9 

99.5% 

8.435 

97.5% 

8 

90.0% 

7 

75.0%  quartile 

7 

50.0%  median 

6 

25.0%  quartile 

6 

10.0% 

5 

2.5% 

5 

0.5% 

4 

0.0%  minimum 

4 

Moments 

Mean 

6.3183594 

Std  Dev 

0.8613322 

Std  Err  Mean 

0.0380659 

Upper  95%  Mean 

6.3931442 

Lower  95%  Mean 

6.2435745 

N 

512 

Figure  32.  Number  of  KLEs  summary  statistics  (1  week) 
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N  KLE.mean 


Quantiles 


100.0% 

maximum 

44.975 

99.5% 

44.6002 

97.5% 

41.5797 

90.0% 

36.626 

75.0% 

quartile 

31.7088 

50.0% 

median 

26.17 

25.0% 

quartile 

21.28 

10.0% 

18.002 

2.5% 

15.013 

0.5% 

13.7824 

0.0% 

minimum 

13.705 

Moments 

Mean 

26.673242 

Std  Dev 

7.0588613 

Std  Err  Mean 

0.31 1 9605 

Upper  95%  Mean 

27.286125 

Lower  95%  Mean 

26.060359 

N 

512 

N  KLE.sd 


Quantiles 

100.0% 

maximum 

4.91438 

99.5% 

4.72368 

97.5% 

4.513 

90.0% 

4.33614 

75.0% 

quartile 

4.16233 

50.0% 

median 

3.94194 

25.0% 

quartile 

3.61776 

10.0% 

3.32107 

2.5% 

2.96161 

0.5% 

2.66713 

0.0% 

minimum 

2.57135 

Moments 

Mean 

3.8818726 

Std  Dev 

0.3944533 

Std  Err  Mean 

0.0174325 

Upper  95%  Mean 

3.9161209 

Lower  95%  Mean 

3.8476244 

N 

512 

N  KLE.min 


Quantiles 


100.0% 

maximum 

38 

99.5% 

37 

97.5% 

33 

90.0% 

26 

75.0% 

quartile 

22 

50.0% 

median 

15 

25.0% 

quartile 

11 

10.0% 

8 

2.5% 

6 

0.5% 

4.565 

0.0% 

minimum 

3 

Moments 

Mean 

16.34375 

Std  Dev 

7.3749855 

Std  Err  Mean 

0.3259314 

Upper  95%  Mean 

16.98408 

Lower  95%  Mean 

15.70342 

N 

512 

N  KLE.max 


Quantiles 

100.0% 

maximum 

54 

99.5% 

51 

97.5% 

50 

90.0% 

46 

75.0% 

quartile 

42 

50.0% 

median 

38 

25.0% 

quartile 

33 

10.0% 

29 

2.5% 

25.825 

0.5% 

22.565 

0.0% 

minimum 

22 

Moments 

Mean 

37.433594 

Std  Dev 

6.3952866 

Std  Err  Mean 

0.2826344 

Upper  95%  Mean 

37.988862 

Lower  95%  Mean 

36.878325 

N 

512 

Figure  33.  Number  of  KLEs  summary  statistics  (9  weeks) 
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N  KLE.mean  N  KLE.sd  N  KLE.min  N  KLE.max 


Quantiles 

Quantiles 

Quantiles 

Quantiles 

100.0% 

maximum 

256.32 

100.0% 

maximum 

32.6262 

100.0% 

maximum 

236 

100.0% 

maximum 

275 

99.5% 

235.666 

99.5% 

28.3336 

99.5% 

203.96 

99.5% 

265.74 

97.5% 

206.398 

97.5% 

24.4195 

97.5% 

173.7 

97.5% 

245.175 

90.0% 

168.359 

90.0% 

19.2627 

90.0% 

121 

90.0% 

215.7 

75.0% 

quartile 

128.385 

75.0% 

quartile 

16.8185 

75.0% 

quartile 

85 

75.0% 

quartile 

173.75 

50.0% 

median 

97.77 

50.0% 

median 

14.0922 

50.0% 

median 

56 

50.0% 

median 

140 

25.0% 

quartile 

72.7087 

25.0% 

quartile 

12.049 

25.0% 

quartile 

38.25 

25.0% 

quartile 

111 

10.0% 

55.3835 

10.0% 

9.89553 

10.0% 

28 

10.0% 

87.3 

2.5% 

40.8741 

2.5% 

6.71971 

2.5% 

21.825 

2.5% 

62.825 

0.5% 

33.5412 

0.5% 

5.69634 

0.5% 

18.565 

0.5% 

52.13 

0.0% 

minimum 

32.03 

0.0% 

minimum 

5.02327 

0.0% 

minimum 

16 

0.0% 

minimum 

49 

Moments 

Moments 

Moments 

Moments 

Mean 

105.29586 

Mean 

14.507469 

Mean 

66.726563 

Mean 

145.2207 

Std  Dev 

43.715026 

Std  Dev 

3.9302358 

Std  Dev 

38.754274 

Std  Dev 

46.811277 

Std  Err  Mean 

1.9319494 

Std  Err  Mean 

0.1736935 

Std  Err  Mean 

1.7127131 

Std  Err  Mean 

2.0687857 

Upper  95%  Mean 

109.0914 

Upper  95%  Mean 

14.848711 

Upper  95%  Mean 

70.091388 

Upper  95%  Mean 

149.28508 

Lower  95%  Mean 

101.50032 

Lower  95%  Mean 

14.166228 

Lower  95%  Mean 

63.361737 

Lower  95%  Mean 

141.15633 

N 

512 

N 

512 

N 

512 

N 

512 

Figure  34.  Number  of  KLEs  summary  statistics  (1  year) 


Table  23  lists  the  summary  statistics  for  all  of  the  output  means  across  all 
three  scenarios. 
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Output 

Response 

1  week 

9  weeks 

1  year 

(mean/sd 

(mean/sd 

(mean/sd 

min/max) 

min/max) 

min/max) 

Nmkle 

1/0 

36.48/144.04 

7905.92/8840.24 

1/1 

1/1879.44 

1/34357.6 

Ntkg 

0.25/0.15 

9.15/45.81 

1987.56/2828.08 

0/0.58 

0/760.69 

0/15503.4 

Nkle 

3.02/0.7 

26.67/7.06 

105.3/43.72 

1.63/4.82 

13.71/44.98 

32.03/256.32 

NHrm 

1.14/0.54 

9.28/4.29 

30.13/17.79 

0.06/2.76 

0.67/23.67 

3.01/118.73 

Nhrk 

0.57/0.46 

4.46/3.27 

11.74/5.39 

0/2.42 

0/15.37 

0/20.78 

Nhrt 

0.42/0.34 

3.51/2.86 

12.34/11.97 

0/1.74 

0/15.9 

0/75.15 

Nhrr 

0.42/0.34 

3.3/2.67 

11.04/10.62 

0/2.38 

0/19.91 

0/70.56 

Npc 

0.46/0.13 

7.15/2.41 

26.16/19.81 

0.13/0.83 

1.66/14.65 

2.23/153.39 

Nac 

0.23/0.13 

4.66/2.56 

26.13/15.36 

0.01/0.75 

0.54/15.24 

3.56/107.63 

Nbc 

0.02/0.03 

0.44/0.5 

2.47/2.92 

0/0.15 

0/3.58 

0/29.44 

NBk 

0.84/0.51 

0.45/0.51 

2.43/2.76 

0/2 

0/3.37 

0/18.5 

Nrc 

0.09/0.08 

1.04/1.01 

4.23/5.43 

0/0.42 

0/5.49 

0/38.77 

Nrk 

0.08/0.08 

1.05/1.02 

4.03/4.83 

0/0.4 

0/5.27 

0/35.89 

Table  23.  Summary  statistics  for  output  response  means 


For  the  number  of  micro-KLEs  ( NMKle )  response,  we  observe  that  exactly 

one  micro-KLE  takes  place  during  the  one-week  scenario.  This  is  most  likely  due 

to  the  proportion  of  Blue  players  (4)  to  Green  players  (17)  used  in  the  scenarios; 

a  Green  player  is  almost  always  available  to  engage,  so  we  never  see  more  than 
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(or  less  than)  one  micro-KLE.  We  also  observe  an  exponential  increase  in  the 
number  of  micro-KLEs  as  model  runtime  increases,  which  is  discussed  in  section 
D.  This  exponential  issue  ties  into  the  number  of  times  knowledge  is  gained 
during  micro-KLEs  ( NTkg ),  but  the  problem  is  with  the  number  of  micro-KLEs 
only,  as  pfCK  is  the  driving  force  for  Ntkg- 

All  of  our  responses  are  nonnegative.  Some  of  their  distributions  are 
highly  skewed,  with  standard  deviations  that  are  quite  large  relative  to  the 
means,  which  is  why  we  report  the  minimum  and  maximum  value  along  with  the 
means  and  standard  deviations.  This  still  results  in  plausible  ranges  for  all  of  the 
output  variables  (except  Nmkle  and  NTkg)  for  all  three  scenarios,  so  our  model  is 
producing  reasonable  responses. 

Only  two  of  our  design  points  produced  significant  outliers.  One  of  these 
included  the  same  outlier;  they  were  the  Nmkle  minimum  boxplot  and  Ntkg 
minimum  boxplot,  both  at  nine  weeks.  This  was  associated  with  design  point  443. 
All  other  design  points  produced  only  one  micro-KLE  and  zero  times  knowledge 
gained,  but  the  outlier  values  were  59  micro-KLEs  and  24  times  knowledge 
gained.  The  third  outlier  was  found  in  the  number  of  Blue  captures  minimum 
boxplot  at  one  year,  and  it  was  associated  with  design  point  63.  Approximately 
90%  of  the  design  points  produced  zero  Blue  captures,  but  this  outlier  value  was 
14.  After  looking  at  the  input  parameter  values  associated  with  these  design 
points,  no  significant  explanation  was  found  for  these  three  outliers  and  we 
attribute  this  to  randomness  within  the  model. 

D.  DISCUSSION  ON  NUMBER  OF  MICRO-KLES 

After  deriving  regression  metamodels  and  partition  tree  models  for  the 
number  of  micro-KLEs  output  response,  we  are  able  to  decipher  which  input 
parameters  are  most  significant  in  predicting  number  of  micro-KLEs,  but  the 
analytical  models  themselves  provide  poor  fits  and  poor  explanations  of  the 
variability.  In  fact,  we  found  that  the  number  of  micro-KLEs  grows  exponentially 
as  scenario  runtime  increases.  In  the  one-week  scenario,  we  always  had  one 
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micro-KLE  occurring,  but  as  we  increase  model  runtime  to  nine  weeks,  we  see  a 
big  jump  in  the  mean  number  of  micro-KLEs  (Figure  35),  and  we  experience 
exponential  growth  as  we  run  the  model  for  one-year  (Figure  36). 

This  is  one  instance  that  might  not  show  up  as  a  problem  if  a  single 
scenario  time  (nine  weeks  for  instance)  was  used.  A  systematic  exploration 
shows  this  anomaly  compared  to  the  other  KLE  Model  output  responses.  After 
verifying  that  the  KLE  Model  logic  was  sound  and  the  implementation  within  Java 
was  correct,  the  anomaly  was  found  to  be  linked  to  the  static  input  parameters 
governing  the  time  a  Blue  player  spends  waiting  for  a  micro-KLE  and  the  time  a 
Blue  player  spends  in  a  micro-KLE. 

From  Table  17,  these  triangle-distributed  time  streams  have  very  small 
modes  compared  to  all  the  other  time  streams  utilized  in  the  model.  The  mode  for 
the  next  scheduled  micro-KLE  time  stream  is  0.5,  and  the  mode  for  the  time 
spent  in  a  micro-KLE  time  stream  is  0.2.  If  there  are  no  Green  players  available 
to  engage,  then  a  Blue  player  could  do  about  34  micro-KLEs  a  day.  With  four 
Blue  players  in  the  model,  and  assuming  a  one-year  scenario,  we  could  see 
upwards  of  49,640  micro-KLEs  in  one-year  combined. 

The  time  streams  were  best-guess  estimates  from  TRAC-Monterey 
analysts,  so  one  solution  is  to  think  more  carefully  about  what  static  time  stream 
distribution  is  used  for  micro-KLEs.  Another  solution  is  that  the  micro-KLE 
functionality  used  in  our  model  may  require  modifications  (such  as  constraints  on 
the  total  number  of  micro-KLEs  that  one  agent  can  conduct  over  the  course  of  a 
week,  or  the  opportunity  to  “do  nothing”  rather  than  initiate  a  micro-KLE  if  no  key 
leader  is  available)  to  meet  TRAC’s  needs  before  any  incorporation  into  the  CG 
Model. 
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Figure  35.  Number  of  micro-KLEs  summary  statistics  (9  weeks) 
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Figure  36.  Number  of  micro-KLEs  summary  statistics  (1  year) 
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V.  WRAP-UP 


We  begin  Chapter  V  by  stating  our  conclusions  as  to  what  we 
accomplished  by  creating  a  KLE  Model  and  analyzing  that  model.  We  then 
discuss  the  significant  contributions  that  were  made  by  conducting  the  research. 
We  end  with  some  discussion  as  to  potential  future  research  opportunities  that 
stem  from  our  research. 

A.  CONCLUSIONS 

The  primary  goal  of  this  research  was  to  develop  a  discrete  event 
simulation  model  for  potential  plug-in  to  the  CG  Model.  This  model  would  take 
the  place  of  Nexus  when  analyzing  KLEs  by  simplifying  the  Nexus  code.  We 
were  able  to  show  that  a  simple  and  understandable  model  can  be  built  using 
Simkit  that  reasonably  models  those  aspects  of  Nexus  needed  for  the  CG  Model. 
Through  the  use  of  event  graphs,  we  were  able  to  represent  the  complexities  of 
KLEs  in  a  visually  understandable  way.  In  addition,  by  using  discrete  event 
simulation  and  event  graphs,  the  KLE  Model  can  be  easily  modified  while  still 
maintaining  the  desired  functionality  of  the  original  model. 

The  purpose  of  the  analysis  was  to  test  the  KLE  Model  in  order  to  verify 
that  it  works  properly,  and  to  gain  an  understanding  of  KLEs  for  areas  of  future 
research  that  can  be  pursued  using  this  model.  Various  insights  can  be  gathered 
from  this  research  and  analysis.  Through  the  use  of  experimental  design,  we 
were  able  to  adequately  analyze  what  input  parameters  are  most  significant  in 
the  KLE  Model  and  how  these  parameters  verify  the  code  implementation.  Using 
the  number  of  KLEs  response  as  an  example,  we  were  also  able  to  see  through 
regression  metamodels  that  output  complexity  increases  with  runtime  as  cross¬ 
component  effects  become  influential.  Our  analysis  identified  four  input 
parameters  that  show  up  most  often  in  regression  metamodels  and  partition  tree 
models  for  the  output  variables,  and  showed  that  are  also  the  most  significant  in 
the  KLE  Model.  Three  of  these  parameters  made  intuitive  sense;  the  fourth,  the 
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probability  of  having  key  leader  critical  knowledge,  can  be  shown  to  make  sense 
as  it  has  cross-component  implications  within  the  model.  Lastly,  we  found  that 
our  model  encountered  difficulties  modeling  micro-KLEs,  but  the  source  of  the 
problem  was  identified  and  properly  addressed. 

B.  SIGNIFICANT  CONTRIBUTIONS 

The  primary  objective  of  this  work  is  to  enhance  the  CG  Model  in  the 
highest  priority  areas  of  dynamic  social  network  relationships  and  persuasion  and 
influence  (Jackson  2009).  We  sought  to  help  satisfy  the  critical  area 
requirements  identified  by  the  U.S.  Army  and  U.S.  Marine  Corps.  By 
incorporating  those  components  of  Nexus  into  the  CG  Model,  this  work  has  the 
potential  to  save  the  Army  and  Marine  Corps  time  and  money  if  and  when  the 
model  becomes  a  wide-scale  decision-making  tool.  This  effort  reduces  long-term 
requirements  for  scenario  file  development  and  model  maintenance.  Lastly,  this 
research  provides  a  better  understanding  of  key  leader  engagements  and  the 
part  they  play  in  cultural  geography. 

C.  FUTURE  RESEARCH  OPPORTUNITIES 

The  KLE  Model  event  graphs  allow  future  researchers  to  identify  where 
modifications  and/or  additions  are  necessary  in  order  to  achieve  a  desired 
outcome.  Improvement  in  the  functionality  of  the  KLE  Model  can  occur  by 
expanding  on  the  behavior  modeling  of  Blue  players  and  Green  players.  The 
behavior  equations  utilized  are  simple  and  easy  to  understand,  but  if  found 
unsatisfactory,  more  complex,  social  theory-based  equations  can  be  applied  in 
the  model.  Also,  Red  player  actions  were  implied  through  various  events,  and 
future  research  could  look  at  the  feasibility  of  adding  a  Red  player  agent  as  a 
separate  entity  and  analyzing  outputs  specific  to  its  utilization. 

This  research  ran  the  KLE  Model  as  a  closed-loop,  stand-alone 
simulation.  Future  research  may  look  into  tailoring  the  KLE  Model  to  the  specifics 
of  the  CG  Model.  Then,  by  using  the  plug-and-play  aspect  of  the  CG  Model,  one 
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could  link  the  KLE  Model  up  and  see  how  the  KLE  Model  outputs  affect  the 
general  population,  and  how  population  behaviors  as  inputs  affect  the  workings 
of  the  KLE  Model. 

The  scenarios  used  in  the  analysis  involved  three  distinct  runtimes:  one 
week,  nine  weeks,  and  one  year.  This  enabled  us  to  look  at  distinct  differences  in 
short-term,  mid-range,  and  long-term  model  execution,  but  nothing  in  between. 
Future  research  might  look  at  including  model  runtime  as  a  parameter  to  further 
explore  runtime  effects  on  the  output  responses.  Additionally,  the  numbers  of 
Blue  players  and  Green  players  were  static  parameters,  as  well  as  the  streams  of 
times  used  in  the  KLE  Model.  Future  research  could  look  at  varying  these 
aspects  in  a  systematic  way  to  study  the  effects  of  varying  numbers  of  players 
and  time  streams. 

Lastly,  due  to  the  large  amount  of  data  collected  from  running  the  model  in 
the  three  scenarios  over  the  13  different  output  variables,  this  research  made  use 
of  simple  techniques  to  analyze  the  KLE  Model.  With  more  time,  more  advanced 
analytical  techniques  could  be  utilized  to  take  a  closer  look  at  the  data  and 
extract  any  insights  or  relationships  that  were  not  shown  in  this  research. 
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